[jira] [Assigned] (SOLR-5349) CloudSolrServer - timeout arguments passed to ZkStateReader are flipped
[
https://issues.apache.org/jira/browse/SOLR-5349?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar reassigned SOLR-5349:
---
Assignee: Shalin Shekhar Mangar
> CloudSolrServer - timeout arguments passed to ZkStateReader are flipped
> ---
>
> Key: SOLR-5349
> URL: https://issues.apache.org/jira/browse/SOLR-5349
> Project: Solr
> Issue Type: Bug
> Components: clients - java, SolrCloud
>Affects Versions: 4.2.1
>Reporter: Ricardo Merizalde
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
>
> The CloudSolrServer makes the following call:
> ZkStateReader zk = new ZkStateReader(zkHost, zkConnectTimeout,
> zkClientTimeout);
> However, the ZkStateReader constructor is defined like this
> public ZkStateReader(String zkServerAddress, int zkClientTimeout, int
> zkClientConnectTimeout) throws InterruptedException, TimeoutException,
> IOException {
--
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-5309) Investigate ShardSplitTest failures
[ https://issues.apache.org/jira/browse/SOLR-5309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794926#comment-13794926 ] Shalin Shekhar Mangar commented on SOLR-5309: - Another one: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/7794/ > Investigate ShardSplitTest failures > --- > > Key: SOLR-5309 > URL: https://issues.apache.org/jira/browse/SOLR-5309 > Project: Solr > Issue Type: Task > Components: SolrCloud >Reporter: Shalin Shekhar Mangar >Assignee: Shalin Shekhar Mangar > > Investigate why ShardSplitTest if failing sporadically. > Some recent failures: > http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3328/ > http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/7760/ > http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/861/ -- 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-5284) Make it possible to filter classification training by Query
Tommaso Teofili created LUCENE-5284: --- Summary: Make it possible to filter classification training by Query Key: LUCENE-5284 URL: https://issues.apache.org/jira/browse/LUCENE-5284 Project: Lucene - Core Issue Type: Bug Components: modules/classification Reporter: Tommaso Teofili Assignee: Tommaso Teofili Fix For: 4.6, 5.0 It's sometimes useful to use only a certain subset of the whole index to train the classifier with. To do that we can pass a Query to be used during the training phase. -- 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-5284) Make it possible to filter classification training by Query
[ https://issues.apache.org/jira/browse/LUCENE-5284?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tommaso Teofili updated LUCENE-5284: Issue Type: Improvement (was: Bug) > Make it possible to filter classification training by Query > --- > > Key: LUCENE-5284 > URL: https://issues.apache.org/jira/browse/LUCENE-5284 > Project: Lucene - Core > Issue Type: Improvement > Components: modules/classification >Reporter: Tommaso Teofili >Assignee: Tommaso Teofili > Fix For: 4.6, 5.0 > > > It's sometimes useful to use only a certain subset of the whole index to > train the classifier with. To do that we can pass a Query to be used during > the training phase. -- 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: Welcome Ryan Ernst as Lucene/Solr committer
Welcome aboard! On Tue, Oct 15, 2013 at 3:24 AM, Han Jiang wrote: > Welcome, Ryan! > > > On Tue, Oct 15, 2013 at 2:13 AM, Ryan Ernst wrote: > >> Thanks Adrian. >> >> I grew up in Bakersfield, CA (colloquially known as "the armpit of >> California"). I escaped and went to Cal Poly for my bachelors in computer >> science, and after a very brief stint working on HPUX, I landed working on >> the Amazon search engine for A9. I especially enjoy working with >> compression and encodings, and hope to experiment there some more with >> Lucene. >> >> Thanks >> Ryan >> >> >> On Mon, Oct 14, 2013 at 10:27 AM, Adrien Grand wrote: >> >>> I'm pleased to announce that Ryan Ernst has accepted to join our ranks >>> as a committer. >>> >>> Ryan has been working on a number of Lucene and Solr issues and >>> recently contributed the new expressions module[1] which allows for >>> compiling javascript expressions into SortField instances with >>> excellent performance since it doesn't rely on a scripting engine but >>> directly generates Java bytecode. This is a very exciting change which >>> will be available in Lucene 4.6. >>> >>> Ryan, it is tradition that you introduce yourself with a brief bio. >>> >>> Congratulations and welcome! >>> >>> [1] https://issues.apache.org/jira/browse/LUCENE-5207 >>> >>> -- >>> Adrien >>> >>> - >>> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >>> For additional commands, e-mail: dev-h...@lucene.apache.org >>> >>> >> > > > -- > Han Jiang > > Team of Search Engine and Web Mining, > School of Electronic Engineering and Computer Science, > Peking University, China >
[jira] [Created] (SOLR-5349) CloudSolrServer - timeout arguments passed to ZkStateReader are flipped
Ricardo Merizalde created SOLR-5349:
---
Summary: CloudSolrServer - timeout arguments passed to
ZkStateReader are flipped
Key: SOLR-5349
URL: https://issues.apache.org/jira/browse/SOLR-5349
Project: Solr
Issue Type: Bug
Components: clients - java, SolrCloud
Affects Versions: 4.2.1
Reporter: Ricardo Merizalde
Priority: Minor
The CloudSolrServer makes the following call:
ZkStateReader zk = new ZkStateReader(zkHost, zkConnectTimeout,
zkClientTimeout);
However, the ZkStateReader constructor is defined like this
public ZkStateReader(String zkServerAddress, int zkClientTimeout, int
zkClientConnectTimeout) throws InterruptedException, TimeoutException,
IOException {
--
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-5280) Rename TermFreqPayloadIterator -> SuggestionIterator
[ https://issues.apache.org/jira/browse/LUCENE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794780#comment-13794780 ] Areek Zillur commented on LUCENE-5280: -- Thanks for committing this! > 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 > > Attachments: LUCENE-5280.patch > > > 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] (LUCENE-5272) OpenBitSet.ensureCapacity does not modify numBits
[
https://issues.apache.org/jira/browse/LUCENE-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794779#comment-13794779
]
ASF subversion and git services commented on LUCENE-5272:
-
Commit 1532162 from [~rcmuir] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1532162 ]
LUCENE-5272: fix test bugs
> 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
>Assignee: Shai Erera
> Fix For: 4.6, 5.0
>
> 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] (LUCENE-5272) OpenBitSet.ensureCapacity does not modify numBits
[
https://issues.apache.org/jira/browse/LUCENE-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794777#comment-13794777
]
ASF subversion and git services commented on LUCENE-5272:
-
Commit 1532161 from [~rcmuir] in branch 'dev/trunk'
[ https://svn.apache.org/r1532161 ]
LUCENE-5272: fix test bugs
> 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
>Assignee: Shai Erera
> Fix For: 4.6, 5.0
>
> 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
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63710 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63710/ 1 tests failed. REGRESSION: org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([75CC8944DFE8ED82:761E4C6DC844A068]:0) at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255) at org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity(TestOpenBitSet.java:341) 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 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:722) Build Log: [...truncated 862 lines...] [junit4] Suite: org.apache.lucene.util.TestOpenBitSet [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet -Dtests.method=testEnsureCapacity -Dtests.seed=75CC8944DFE8ED82 -Dtests.slow=true -Dtests.locale=es_PR -Dtests.timezone=GB -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.12s J6 | TestOpenBitSet.testEnsureCapacity <<< [junit4]> Throwable #1: java.lang.AssertionError [junit4]>at __randomizedtesting.SeedInfo.seed([75CC8944DFE8ED82:761E4C6DC844A068]:0) [junit4]>at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255) [junit4]
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome, Ryan! On Tue, Oct 15, 2013 at 2:13 AM, Ryan Ernst wrote: > Thanks Adrian. > > I grew up in Bakersfield, CA (colloquially known as "the armpit of > California"). I escaped and went to Cal Poly for my bachelors in computer > science, and after a very brief stint working on HPUX, I landed working on > the Amazon search engine for A9. I especially enjoy working with > compression and encodings, and hope to experiment there some more with > Lucene. > > Thanks > Ryan > > > On Mon, Oct 14, 2013 at 10:27 AM, Adrien Grand wrote: > >> I'm pleased to announce that Ryan Ernst has accepted to join our ranks >> as a committer. >> >> Ryan has been working on a number of Lucene and Solr issues and >> recently contributed the new expressions module[1] which allows for >> compiling javascript expressions into SortField instances with >> excellent performance since it doesn't rely on a scripting engine but >> directly generates Java bytecode. This is a very exciting change which >> will be available in Lucene 4.6. >> >> Ryan, it is tradition that you introduce yourself with a brief bio. >> >> Congratulations and welcome! >> >> [1] https://issues.apache.org/jira/browse/LUCENE-5207 >> >> -- >> Adrien >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > -- Han Jiang Team of Search Engine and Web Mining, School of Electronic Engineering and Computer Science, Peking University, China
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63707 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63707/ 1 tests failed. REGRESSION: org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([FFF822150E5881D:C2D47084749C5F7]:0) at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255) at org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity(TestOpenBitSet.java:353) 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 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:722) Build Log: [...truncated 848 lines...] [junit4] Suite: org.apache.lucene.util.TestOpenBitSet [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet -Dtests.method=testEnsureCapacity -Dtests.seed=FFF822150E5881D -Dtests.slow=true -Dtests.locale=sq -Dtests.timezone=Australia/Queensland -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.05s J2 | TestOpenBitSet.testEnsureCapacity <<< [junit4]> Throwable #1: java.lang.AssertionError [junit4]>at __randomizedtesting.SeedInfo.seed([FFF822150E5881D:C2D47084749C5F7]:0) [junit4]>at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255)
[JENKINS] Lucene-4x-Linux-Java7-64-test-only - Build # 17 - Failure!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java7-64-test-only/17/ 1 tests failed. REGRESSION: org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([E6F56E6802216577:E527AB41158D289D]:0) at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255) at org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity(TestOpenBitSet.java:353) 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 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:722) Build Log: [...truncated 597 lines...] [junit4] Suite: org.apache.lucene.util.TestOpenBitSet [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet -Dtests.method=testEnsureCapacity -Dtests.seed=E6F56E6802216577 -Dtests.slow=true -Dtests.locale=pl -Dtests.timezone=Mideast/Riyadh89 -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.23s J4 | TestOpenBitSet.testEnsureCapacity <<< [junit4]> Throwable #1: java.lang.AssertionError [junit4]>at __randomizedtesting.SeedInfo.seed([E6F56E6802216577:E527AB41158D289D]:0) [junit4]>at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255) [jun
[jira] [Commented] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794683#comment-13794683 ] SooMyung Lee commented on LUCENE-4956: -- [~thetaphi] Thank you for your advice, I have opened this source code in sourceforege since 2009 and have many users. but, nobody told me the bugs and I also didn't know that. Christian and myself will fix the bugs soon. Thank you again. > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: kr.analyzer.4x.tar, lucene-4956.patch, lucene4956.patch, > LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- 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.8.0-ea-b106) - Build # 7795 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/7795/ Java: 64bit/jdk1.8.0-ea-b106 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC 1 tests failed. REGRESSION: org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([8245A194D9CA6CAF:819764BDCE662145]:0) at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255) at org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity(TestOpenBitSet.java:353) 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 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 409 lines...] [junit4] Suite: org.apache.lucene.util.TestOpenBitSet [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet -Dtests.method=testEnsureCapacity -Dtests.seed=8245A194D9CA6CAF -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=sr_ME_#Latn -Dtests.timezone=Europe/Istanbul -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.01s J1 | TestOpenBitSet.testEnsureCapacity <<< [junit4]> Throwable #1: java.lang.AssertionError [junit4]>at __randomizedtesting.SeedInfo.seed([8245A194D9CA6CAF:819764BDCE662145]:0
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_40) - Build # 7890 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/7890/ Java: 64bit/jdk1.7.0_40 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. FAILED: org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([488C09AF331A64BD:4B5ECC8624B62957]:0) at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255) at org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity(TestOpenBitSet.java:353) 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 879 lines...] [junit4] Suite: org.apache.lucene.util.TestOpenBitSet [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet -Dtests.method=testEnsureCapacity -Dtests.seed=488C09AF331A64BD -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=en_US -Dtests.timezone=America/Rankin_Inlet -Dtests.file.encoding=ISO-8859-1 [junit4] FAILURE 0.01s J0 | TestOpenBitSet.testEnsureCapacity <<< [junit4]> Throwable #1: java.lang.AssertionError [junit4]>at __randomizedtesting.SeedInfo.seed([488C09AF331A64BD:4B5ECC8624B62957]:0) [junit4]
[jira] [Updated] (SOLR-4992) Solr queries don't propagate Java OutOfMemoryError back to the JVM
[
https://issues.apache.org/jira/browse/SOLR-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-4992:
--
Attachment: SOLR-4992.patch
Here is a first (somewhat conservative) pass at improving the situation.
> Solr queries don't propagate Java OutOfMemoryError back to the JVM
> --
>
> Key: SOLR-4992
> URL: https://issues.apache.org/jira/browse/SOLR-4992
> Project: Solr
> Issue Type: Bug
> Components: search, SolrCloud, update
>Affects Versions: 4.3.1
>Reporter: Daniel Collins
>Assignee: Mark Miller
> Fix For: 4.6, 5.0
>
> Attachments: SOLR-4992.patch
>
>
> Solr (specifically SolrDispatchFilter.doFilter() but there might be other
> places) handle generic java.lang.Throwable errors but that "hides"
> OutOfMemoryError scenarios.
> IndexWriter does this too but that has a specific exclusion for OOM scenarios
> and handles them explicitly (stops committing and just logs to the
> transaction log).
> {noformat}
> Example Stack trace:
> 2013-06-26 19:31:33,801 [qtp632640515-62] ERROR
> solr.servlet.SolrDispatchFilter Q:22 -
> null:java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap
> space
> at
> org.apache.solr.servlet.SolrDispatchFilter.sendError(SolrDispatchFilter.java:670)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:380)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:155)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1423)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:450)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:138)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:564)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:213)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1083)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:379)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:175)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1017)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:136)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:258)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:445)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:260)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:225)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:596)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:527)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.OutOfMemoryError: Java heap space
> {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
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63700 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63700/ 1 tests failed. REGRESSION: org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([D25FEE091005583E:D18D2B2007A915D4]:0) at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255) at org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity(TestOpenBitSet.java:338) 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 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:722) Build Log: [...truncated 357 lines...] [junit4] Suite: org.apache.lucene.util.TestOpenBitSet [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet -Dtests.method=testEnsureCapacity -Dtests.seed=D25FEE091005583E -Dtests.slow=true -Dtests.locale=sq_AL -Dtests.timezone=America/Belem -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.23s J4 | TestOpenBitSet.testEnsureCapacity <<< [junit4]> Throwable #1: java.lang.AssertionError [junit4]>at __randomizedtesting.SeedInfo.seed([D25FEE091005583E:D18D2B2007A915D4]:0) [junit4]>at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255)
[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-tabpanel&focusedCommentId=13794615#comment-13794615
]
Mark Miller commented on SOLR-4327:
---
See SOLR-4992 if you are interested in the catching Throwable issue.
> 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
[jira] [Commented] (SOLR-4992) Solr queries don't propagate Java OutOfMemoryError back to the JVM
[
https://issues.apache.org/jira/browse/SOLR-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794616#comment-13794616
]
Mark Miller commented on SOLR-4992:
---
I think for some cases it does.
It's a little painful for closing collections of items or if you need to close
a lot of items serially, nesting one finally after another.
It does seem like we should probably stop catching throwable in most cases
anyway. In some cases, you might still catch it, log something and then throw
if instanceOf Error I think, but in general, we need OOM's to bubble up. It
seems like the best way to ensure that is to try and minimize use of catch
(Throwable...
> Solr queries don't propagate Java OutOfMemoryError back to the JVM
> --
>
> Key: SOLR-4992
> URL: https://issues.apache.org/jira/browse/SOLR-4992
> Project: Solr
> Issue Type: Bug
> Components: search, SolrCloud, update
>Affects Versions: 4.3.1
>Reporter: Daniel Collins
>Assignee: Mark Miller
> Fix For: 4.6, 5.0
>
>
> Solr (specifically SolrDispatchFilter.doFilter() but there might be other
> places) handle generic java.lang.Throwable errors but that "hides"
> OutOfMemoryError scenarios.
> IndexWriter does this too but that has a specific exclusion for OOM scenarios
> and handles them explicitly (stops committing and just logs to the
> transaction log).
> {noformat}
> Example Stack trace:
> 2013-06-26 19:31:33,801 [qtp632640515-62] ERROR
> solr.servlet.SolrDispatchFilter Q:22 -
> null:java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap
> space
> at
> org.apache.solr.servlet.SolrDispatchFilter.sendError(SolrDispatchFilter.java:670)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:380)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:155)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1423)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:450)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:138)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:564)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:213)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1083)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:379)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:175)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1017)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:136)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:258)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:445)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:260)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:225)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:596)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:527)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.OutOfMemoryError: Java heap space
> {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
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome, Ryan! -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com 14. okt. 2013 kl. 19:27 skrev Adrien Grand : > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > 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
Re: Should build fail if test does not exist?
On Mon, Oct 14, 2013 at 3:38 PM, Dawid Weiss wrote: > You need to know your tools -- we should make it more explicit that > these filters are glob patterns rather than hide this even deeper. Actually I find it very strange that they are glob patterns, and I never (intentionally!) take advantage of that. When I specify a test case and test method, it's always because I'm trying to specify precisely one. Is this (the "globbing") really an important feature? Is it somehow necessary in the implementation for other reasons? Another (third) trap I've hit is trying to run a single method, but accidentally running two because the first method is a prefix of the second one ... when this happens, I go and rename the methods so there is no prefix anymore. 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
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! koji (13/10/15 2:27), Adrien Grand wrote: I'm pleased to announce that Ryan Ernst has accepted to join our ranks as a committer. Ryan has been working on a number of Lucene and Solr issues and recently contributed the new expressions module[1] which allows for compiling javascript expressions into SortField instances with excellent performance since it doesn't rely on a scripting engine but directly generates Java bytecode. This is a very exciting change which will be available in Lucene 4.6. Ryan, it is tradition that you introduce yourself with a brief bio. Congratulations and welcome! [1] https://issues.apache.org/jira/browse/LUCENE-5207 -- http://soleami.com/blog/automatically-acquiring-synonym-knowledge-from-wikipedia.html - 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.7.0_40) - Build # 7889 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/7889/ Java: 64bit/jdk1.7.0_40 -XX:+UseCompressedOops -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([9FFF58E1B5A04761:9C2D9DC8A20C0A8B]:0) at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255) at org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity(TestOpenBitSet.java:353) 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 1048 lines...] [junit4] Suite: org.apache.lucene.util.TestOpenBitSet [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet -Dtests.method=testEnsureCapacity -Dtests.seed=9FFF58E1B5A04761 -Dtests.multiplier=3 -Dtests.slow=true -Dtests.locale=fi_FI -Dtests.timezone=America/Indianapolis -Dtests.file.encoding=ISO-8859-1 [junit4] FAILURE 0.01s J1 | TestOpenBitSet.testEnsureCapacity <<< [junit4]> Throwable #1: java.lang.AssertionError [junit4]>at __randomizedtesting.SeedInfo.seed([9FFF58E1B5A04761:9C2D9DC8A20C0A8B]:0)
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63698 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63698/ 1 tests failed. REGRESSION: org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([F8B09207CDF2BD2:C59CC096B736638]:0) at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255) at org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity(TestOpenBitSet.java:341) 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 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:722) Build Log: [...truncated 857 lines...] [junit4] Suite: org.apache.lucene.util.TestOpenBitSet [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet -Dtests.method=testEnsureCapacity -Dtests.seed=F8B09207CDF2BD2 -Dtests.slow=true -Dtests.locale=en -Dtests.timezone=America/Rio_Branco -Dtests.file.encoding=US-ASCII [junit4] FAILURE 0.09s J0 | TestOpenBitSet.testEnsureCapacity <<< [junit4]> Throwable #1: java.lang.AssertionError [junit4]>at __randomizedtesting.SeedInfo.seed([F8B09207CDF2BD2:C59CC096B736638]:0) [junit4]>at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255)
Re: Welcome Ryan Ernst as Lucene/Solr committer
Nice, nice, more encoding compression on the way :) Otis On Mon, Oct 14, 2013 at 1:27 PM, Adrien Grand wrote: > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > 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
[JENKINS] Lucene-4x-Linux-Java7-64-test-only - Build # 9 - Failure!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java7-64-test-only/9/ 1 tests failed. REGRESSION: org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([5C943C938F6807FC:5F46F9BA98C44A16]:0) at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255) at org.apache.lucene.util.TestOpenBitSet.testEnsureCapacity(TestOpenBitSet.java:341) 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 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:722) Build Log: [...truncated 155 lines...] [junit4] Suite: org.apache.lucene.util.TestOpenBitSet [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestOpenBitSet -Dtests.method=testEnsureCapacity -Dtests.seed=5C943C938F6807FC -Dtests.slow=true -Dtests.locale=zh_HK -Dtests.timezone=Asia/Damascus -Dtests.file.encoding=US-ASCII [junit4] FAILURE 0.22s J4 | TestOpenBitSet.testEnsureCapacity <<< [junit4]> Throwable #1: java.lang.AssertionError [junit4]>at __randomizedtesting.SeedInfo.seed([5C943C938F6807FC:5F46F9BA98C44A16]:0) [junit4]>at org.apache.lucene.util.OpenBitSet.fastSet(OpenBitSet.java:255) [j
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! - Mark On Oct 14, 2013, at 1:27 PM, Adrien Grand wrote: > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > 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-5236) Use broadword bit selection in EliasFanoDecoder
[ https://issues.apache.org/jira/browse/LUCENE-5236?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794512#comment-13794512 ] Paul Elschot commented on LUCENE-5236: -- I have no objection at all to committing. Needless to say that I am pleasantly surprised with these benchmark results. On my 32 bit machine FixedBitSet does better in general, i.e. the others do worse in the results. But the trends between the others are quite similar. So it's really time to upgrade to 64-bit. Mostly talking to myself, but in case there still are older production machines out there... Fixing FixedBitSet.bits2words involves changing the int numBits arguments in the FixedBitSet constructors to long, and testing whether the result of bits2words is smaller than max int. I don't see Lucene segments growing above 2G docs real soon now, so this is not urgent for FixedBitSet. > 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
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! Tommaso 2013/10/14 Adrien Grand > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! Christian 2013/10/15 2:27、Adrien Grand のメッセージ: > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > 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
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! On Monday, October 14, 2013 at 7:27 PM, Adrien Grand wrote: > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > (mailto:dev-unsubscr...@lucene.apache.org) > For additional commands, e-mail: dev-h...@lucene.apache.org > (mailto:dev-h...@lucene.apache.org) > >
[jira] [Resolved] (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 resolved LUCENE-5272.
Resolution: Fixed
Fix Version/s: 5.0
4.6
Assignee: Shai Erera
Lucene Fields: New,Patch Available (was: New)
Committed to trunk and 4x.
> 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
>Assignee: Shai Erera
> Fix For: 4.6, 5.0
>
> 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] (LUCENE-5272) OpenBitSet.ensureCapacity does not modify numBits
[
https://issues.apache.org/jira/browse/LUCENE-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794489#comment-13794489
]
ASF subversion and git services commented on LUCENE-5272:
-
Commit 1532099 from [~shaie] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1532099 ]
LUCENE-5272: OpenBitSet.ensureCapacity does not modify numBits
> 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
> Fix For: 4.6, 5.0
>
> 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] (LUCENE-5272) OpenBitSet.ensureCapacity does not modify numBits
[
https://issues.apache.org/jira/browse/LUCENE-5272?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794483#comment-13794483
]
ASF subversion and git services commented on LUCENE-5272:
-
Commit 1532093 from [~shaie] in branch 'dev/trunk'
[ https://svn.apache.org/r1532093 ]
LUCENE-5272: OpenBitSet.ensureCapacity does not modify numBits
> 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-5331) SolrCloud 4.5 bulk add errors
[
https://issues.apache.org/jira/browse/SOLR-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794481#comment-13794481
]
Uwe Schindler commented on SOLR-5331:
-
Hi Chris, just for completeness:
Do you use/enforce multipart POST? If this is the case, this commit could cause
this: r1469946 (SOLR-4358: HttpSolrServer now supports forcing multipart
requests). If you post this as multipart (and not as a single raw and large
file), it may hit the multipart limit. Every file of a multipart request must
be smaller than the configured limit (see above). So you have to raise
multipartUploadLimitInKB. Mentioning "bulk mode" seem to suggest this to me.
Unfortunately I have no idea about SolrJ's internal handling, so just digging.
> SolrCloud 4.5 bulk add errors
> -
>
> Key: SOLR-5331
> URL: https://issues.apache.org/jira/browse/SOLR-5331
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.5
>Reporter: Chris
> Fix For: 4.5.1
>
>
> Since Solr 4.5 bulk adding documents via SolrJ (at least) is causing errors.
> // build array list of SolrInputDocuments
> server.add(docs);
> I've tried with CUSS (which swallows exceptions as expected) however they are
> shown in the logs on server, and with CloudSolrServer which is returning the
> errors as well as seeing them in the server logs.
> I've tried downgrading my SolrJ to 4.4, still errors so looks like a
> regression in the server code. Reverting to Solr 4.4 on server and I don't
> get errors (however run into deadlock issues).
> I raised this issue in IRC - NOT the mailing list, and elyorag suggested
> opening a ticket, and to mention this has now been discussed in IRC.
> The exceptions would indicate I'm attempting to do multiple operations in a
> single request which is malformed. I am not, I am only attempting to add
> documents.
> Stack traces seen here:
> 14:57:13 ERROR SolrCmdDistributor shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
>
> shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
> at [row,col {unknown-source}]: [18,327]
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:424)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:401)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:375)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
>
> org.apache.solr.common.SolrException: Illegal to have multiple roots
> (start tag in epilog?).
> at [row,col {unknown-source}]: [7,6314]
> at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:176)
> at
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invok
[jira] [Comment Edited] (SOLR-5331) SolrCloud 4.5 bulk add errors
[
https://issues.apache.org/jira/browse/SOLR-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794458#comment-13794458
]
Uwe Schindler edited comment on SOLR-5331 at 10/14/13 8:46 PM:
---
Hi Chris,
this setting affects all servlet containers. Shawn's explanation was not fully
correct: Solr does not set anything in the servlet container. Since Solr 4.1.0,
any settings in the container about charset, request size,.. don't have any
effect on Solr anymore. Especially Tomcat was the source of all bugs (because
you had to configure Tomcat to use UTF-8) for query encoding.
SOLR-4265 and SOLR-4283 changed this: All query parameters, uploaded files,...
are now handled directly by the dispatcher servlet. It reads the POST data from
an input stream, it does not let Tomcat parse them.
The Tomcat setting only affects the maximum size of POSTed form data if parsed
by Tomcat itsself (means those &...&...&-encoded data). As parsing is done
in Solr, the corresponding setting in tomcat is: formdataUploadLimitInKB (for
form data encoded like URL params) and multipartUploadLimitInKB (for file
uploads) in the solrconfig.xml.
was (Author: thetaphi):
Hi Chris,
this setting affects all servlet containers. Shawn's explanation was not fully
correct: Solr does not set anything in the servlet container. Since Solr 4.1.0,
any settings about charset, request size,.. don't have any effect on Solr
anymore. Especially Tomcat was the source of all bugs (because you had to
configure Tomcat to use UTF-8) for query encoding.
SOLR-4265 and SOLR-4283 changed this: All query parameters, uploaded files,...
are now handled directly by the dispatcher servlet. It reads the POST data from
an input stream, it does not let Tomcat parse them.
The Tomcat setting only affects the maximum size of POSTed form data if parsed
by Tomcat itsself (means those &...&...&-encoded data). As parsing is done
in Solr, the corresponding setting in tomcat is: formdataUploadLimitInKB (for
form data encoded like URL params) and multipartUploadLimitInKB (for file
uploads) in the solrconfig.xml.
> SolrCloud 4.5 bulk add errors
> -
>
> Key: SOLR-5331
> URL: https://issues.apache.org/jira/browse/SOLR-5331
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.5
>Reporter: Chris
> Fix For: 4.5.1
>
>
> Since Solr 4.5 bulk adding documents via SolrJ (at least) is causing errors.
> // build array list of SolrInputDocuments
> server.add(docs);
> I've tried with CUSS (which swallows exceptions as expected) however they are
> shown in the logs on server, and with CloudSolrServer which is returning the
> errors as well as seeing them in the server logs.
> I've tried downgrading my SolrJ to 4.4, still errors so looks like a
> regression in the server code. Reverting to Solr 4.4 on server and I don't
> get errors (however run into deadlock issues).
> I raised this issue in IRC - NOT the mailing list, and elyorag suggested
> opening a ticket, and to mention this has now been discussed in IRC.
> The exceptions would indicate I'm attempting to do multiple operations in a
> single request which is malformed. I am not, I am only attempting to add
> documents.
> Stack traces seen here:
> 14:57:13 ERROR SolrCmdDistributor shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
>
> shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
> at [row,col {unknown-source}]: [18,327]
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:424)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:401)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:375)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
>
> org.apache.solr.common.SolrExceptio
[jira] [Commented] (SOLR-5331) SolrCloud 4.5 bulk add errors
[
https://issues.apache.org/jira/browse/SOLR-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794458#comment-13794458
]
Uwe Schindler commented on SOLR-5331:
-
Hi Chris,
this setting affects all servlet containers. Shawn's explanation was not fully
correct: Solr does not set anything in the servlet container. Since Solr 4.1.0,
any settings about charset, request size,.. don't have any effect on Solr
anymore. Especially Tomcat was the source of all bugs (because you had to
configure Tomcat to use UTF-8) for query encoding.
SOLR-4265 and SOLR-4283 changed this: All query parameters, uploaded files,...
are now handled directly by the dispatcher servlet. It reads the POST data from
an input stream, it does not let Tomcat parse them.
The Tomcat setting only affects the maximum size of POSTed form data if parsed
by Tomcat itsself (means those &...&...&-encoded data). As parsing is done
in Solr, the corresponding setting in tomcat is: formdataUploadLimitInKB (for
form data encoded like URL params) and multipartUploadLimitInKB (for file
uploads) in the solrconfig.xml.
> SolrCloud 4.5 bulk add errors
> -
>
> Key: SOLR-5331
> URL: https://issues.apache.org/jira/browse/SOLR-5331
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.5
>Reporter: Chris
> Fix For: 4.5.1
>
>
> Since Solr 4.5 bulk adding documents via SolrJ (at least) is causing errors.
> // build array list of SolrInputDocuments
> server.add(docs);
> I've tried with CUSS (which swallows exceptions as expected) however they are
> shown in the logs on server, and with CloudSolrServer which is returning the
> errors as well as seeing them in the server logs.
> I've tried downgrading my SolrJ to 4.4, still errors so looks like a
> regression in the server code. Reverting to Solr 4.4 on server and I don't
> get errors (however run into deadlock issues).
> I raised this issue in IRC - NOT the mailing list, and elyorag suggested
> opening a ticket, and to mention this has now been discussed in IRC.
> The exceptions would indicate I'm attempting to do multiple operations in a
> single request which is malformed. I am not, I am only attempting to add
> documents.
> Stack traces seen here:
> 14:57:13 ERROR SolrCmdDistributor shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
>
> shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
> at [row,col {unknown-source}]: [18,327]
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:424)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:401)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:375)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
>
> org.apache.solr.common.SolrException: Illegal to have multiple roots
> (start tag in epilog?).
> at [row,col {unknown-source}]: [7,6314]
> at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:176)
> at
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilte
[jira] [Commented] (SOLR-5331) SolrCloud 4.5 bulk add errors
[
https://issues.apache.org/jira/browse/SOLR-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794437#comment-13794437
]
Chris commented on SOLR-5331:
-
Shawn is this also applicable for Tomcat? I have set the max post size to 100MB
there
> SolrCloud 4.5 bulk add errors
> -
>
> Key: SOLR-5331
> URL: https://issues.apache.org/jira/browse/SOLR-5331
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.5
>Reporter: Chris
> Fix For: 4.5.1
>
>
> Since Solr 4.5 bulk adding documents via SolrJ (at least) is causing errors.
> // build array list of SolrInputDocuments
> server.add(docs);
> I've tried with CUSS (which swallows exceptions as expected) however they are
> shown in the logs on server, and with CloudSolrServer which is returning the
> errors as well as seeing them in the server logs.
> I've tried downgrading my SolrJ to 4.4, still errors so looks like a
> regression in the server code. Reverting to Solr 4.4 on server and I don't
> get errors (however run into deadlock issues).
> I raised this issue in IRC - NOT the mailing list, and elyorag suggested
> opening a ticket, and to mention this has now been discussed in IRC.
> The exceptions would indicate I'm attempting to do multiple operations in a
> single request which is malformed. I am not, I am only attempting to add
> documents.
> Stack traces seen here:
> 14:57:13 ERROR SolrCmdDistributor shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
>
> shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
> at [row,col {unknown-source}]: [18,327]
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:424)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:401)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:375)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
>
> org.apache.solr.common.SolrException: Illegal to have multiple roots
> (start tag in epilog?).
> at [row,col {unknown-source}]: [7,6314]
> at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:176)
> at
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
> at
> org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java
[JENKINS] Lucene-4.5.1-Linux-Java7-64-test-only - Build # 1 - Failure!
Build: builds.flonkings.com/job/Lucene-4.5.1-Linux-Java7-64-test-only/1/ All tests passed Build Log: [...truncated 9724 lines...] ERROR: No artifacts are configured for archiving. You probably forgot to set the file pattern, so please go back to the configuration and specify it. If you really did mean to archive all the files in the workspace, please specify "**" Build step 'Archive the artifacts' changed build result to FAILURE 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-trunk-Linux-Java7-64-test-only - Build # 63672 - Failure!
I committed a fix; should fix all the other recent bloom failures. Mike McCandless http://blog.mikemccandless.com On Mon, Oct 14, 2013 at 2:47 PM, wrote: > Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63672/ > > 1 tests failed. > REGRESSION: org.apache.lucene.index.TestIndexWriterOutOfFileDescriptors.test > > Error Message: > file "_e_TestBloomFilteredLucene41Postings_0.tim" already exists; > siFiles=[_e.si] > > Stack Trace: > java.lang.AssertionError: file "_e_TestBloomFilteredLucene41Postings_0.tim" > already exists; siFiles=[_e.si] > at > __randomizedtesting.SeedInfo.seed([5DFACE3F0360D45:8D8B93395ECA60BD]:0) > at > org.apache.lucene.index.IndexWriter.copySegmentAsIs(IndexWriter.java:2672) > at > org.apache.lucene.index.IndexWriter.addIndexes(IndexWriter.java:2433) > at > org.apache.lucene.index.TestIndexWriterOutOfFileDescriptors.test(TestIndexWriterOutOfFileDescriptors.java:76) > 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 > 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:722) > > > > > Build Log: >
[jira] [Updated] (LUCENE-5274) Teach fast FastVectorHighlighter to highlight "child fields" with parent fields
[ https://issues.apache.org/jira/browse/LUCENE-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nik Everett updated LUCENE-5274: Attachment: LUCENE-5274.patch Removed analyzer dependency and added tests covering synonyms. > Teach fast FastVectorHighlighter to highlight "child fields" with parent > fields > --- > > Key: LUCENE-5274 > URL: https://issues.apache.org/jira/browse/LUCENE-5274 > Project: Lucene - Core > Issue Type: Improvement > Components: core/other >Reporter: Nik Everett >Assignee: Adrien Grand >Priority: Minor > Attachments: LUCENE-5274.patch > > > I've been messing around with the FastVectorHighlighter and it looks like I > can teach it to highlight matches on "child fields". Like this query: > foo:scissors foo_exact:running > would highlight foo like this: > running with scissors > Where foo is stored WITH_POSITIONS_OFFSETS and foo_plain is an unstored copy > of foo a different analyzer and its own WITH_POSITIONS_OFFSETS. > This would make queries that perform weighted matches against different > analyzers much more convenient to highlight. > I have working code and test cases but they are hacked into Elasticsearch. > I'd love to Lucene-ify if you'll take them. -- 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-5268) Cutover more postings formats to the inverted "pull" API
[ https://issues.apache.org/jira/browse/LUCENE-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794426#comment-13794426 ] ASF subversion and git services commented on LUCENE-5268: - Commit 1532060 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1532060 ] LUCENE-5268: fix test failures: bloom must first call delegate.write, then write its own > Cutover more postings formats to the inverted "pull" API > > > Key: LUCENE-5268 > URL: https://issues.apache.org/jira/browse/LUCENE-5268 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0 > > Attachments: LUCENE-5268.patch, LUCENE-5268.patch > > > In LUCENE-5123, we added a new, more flexible, "pull" API for writing > postings. This API allows the postings format to iterate the > fields/terms/postings more than once, and mirrors the API for writing > doc values. > But that was just the first step (only SimpleText was cutover to the > new API). I want to cutover more components, so we can (finally) > e.g. play with different encodings depending on the term's postings, > such as using a bitset for high freq DOCS_ONLY terms (LUCENE-5052). -- 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-5274) Teach fast FastVectorHighlighter to highlight "child fields" with parent fields
[ https://issues.apache.org/jira/browse/LUCENE-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nik Everett updated LUCENE-5274: Attachment: (was: LUCENE-5274.patch) > Teach fast FastVectorHighlighter to highlight "child fields" with parent > fields > --- > > Key: LUCENE-5274 > URL: https://issues.apache.org/jira/browse/LUCENE-5274 > Project: Lucene - Core > Issue Type: Improvement > Components: core/other >Reporter: Nik Everett >Assignee: Adrien Grand >Priority: Minor > Attachments: LUCENE-5274.patch > > > I've been messing around with the FastVectorHighlighter and it looks like I > can teach it to highlight matches on "child fields". Like this query: > foo:scissors foo_exact:running > would highlight foo like this: > running with scissors > Where foo is stored WITH_POSITIONS_OFFSETS and foo_plain is an unstored copy > of foo a different analyzer and its own WITH_POSITIONS_OFFSETS. > This would make queries that perform weighted matches against different > analyzers much more convenient to highlight. > I have working code and test cases but they are hacked into Elasticsearch. > I'd love to Lucene-ify if you'll take them. -- 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 # 63685 - Failure!
I'm pretty sure this is the same root cause as the previous failure
... I'll commit a fix (from Rob!) shortly ...
Mike McCandless
http://blog.mikemccandless.com
On Mon, Oct 14, 2013 at 3:51 PM, wrote:
> Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63685/
>
> 1 tests failed.
> REGRESSION:
> org.apache.lucene.index.TestIndexWriterDelete.testUpdatesOnDiskFull
>
> Error Message:
> MockDirectoryWrapper: cannot close: there are still open files:
> {_7_TestBloomFilteredLucene41Postings_0.tim=1,
> _7_TestBloomFilteredLucene41Postings_0.tip=1,
> _7_TestBloomFilteredLucene41Postings_0.pos=1,
> _7_TestBloomFilteredLucene41Postings_0.doc=1}
>
> Stack Trace:
> java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are
> still open files: {_7_TestBloomFilteredLucene41Postings_0.tim=1,
> _7_TestBloomFilteredLucene41Postings_0.tip=1,
> _7_TestBloomFilteredLucene41Postings_0.pos=1,
> _7_TestBloomFilteredLucene41Postings_0.doc=1}
> at
> __randomizedtesting.SeedInfo.seed([145B72EB142D4F7C:70BDB4D8B027E0DA]:0)
> at
> org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:623)
> at
> org.apache.lucene.index.TestIndexWriterDelete.doTestOperationsOnDiskFull(TestIndexWriterDelete.java:698)
> at
> org.apache.lucene.index.TestIndexWriterDelete.testUpdatesOnDiskFull(TestIndexWriterDelete.java:489)
> 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
> 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(TestRuleI
Re: [JENKINS] Lucene-4x-Linux-Java7-64-test-only - Build # 1 - Failure!
sorry for the noise - I just added tasks for 4.x and 4.5.1 next to the trunk task simon On Mon, Oct 14, 2013 at 10:10 PM, wrote: > Build: builds.flonkings.com/job/Lucene-4x-Linux-Java7-64-test-only/1/ > > All tests passed > > Build Log: > [...truncated 9772 lines...] > ERROR: No artifacts found that match the file pattern "heapdumps/**". > Configuration error? > ERROR: ‘heapdumps/**’ doesn’t match anything, but ‘**’ does. Perhaps that’s > what you mean? > Build step 'Archive the artifacts' changed build result to FAILURE > Recording test results > Email was triggered for: Failure > Sending email for trigger: Failure > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-4x-Linux-Java7-64-test-only - Build # 1 - Failure!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java7-64-test-only/1/ All tests passed Build Log: [...truncated 9772 lines...] ERROR: No artifacts found that match the file pattern "heapdumps/**". Configuration error? ERROR: ‘heapdumps/**’ doesn’t match anything, but ‘**’ does. Perhaps that’s what you mean? Build step 'Archive the artifacts' changed build result to FAILURE Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63685 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63685/
1 tests failed.
REGRESSION: org.apache.lucene.index.TestIndexWriterDelete.testUpdatesOnDiskFull
Error Message:
MockDirectoryWrapper: cannot close: there are still open files:
{_7_TestBloomFilteredLucene41Postings_0.tim=1,
_7_TestBloomFilteredLucene41Postings_0.tip=1,
_7_TestBloomFilteredLucene41Postings_0.pos=1,
_7_TestBloomFilteredLucene41Postings_0.doc=1}
Stack Trace:
java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are still
open files: {_7_TestBloomFilteredLucene41Postings_0.tim=1,
_7_TestBloomFilteredLucene41Postings_0.tip=1,
_7_TestBloomFilteredLucene41Postings_0.pos=1,
_7_TestBloomFilteredLucene41Postings_0.doc=1}
at
__randomizedtesting.SeedInfo.seed([145B72EB142D4F7C:70BDB4D8B027E0DA]:0)
at
org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:623)
at
org.apache.lucene.index.TestIndexWriterDelete.doTestOperationsOnDiskFull(TestIndexWriterDelete.java:698)
at
org.apache.lucene.index.TestIndexWriterDelete.testUpdatesOnDiskFull(TestIndexWriterDelete.java:489)
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
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(T
[jira] [Commented] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).
[ https://issues.apache.org/jira/browse/LUCENE-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794394#comment-13794394 ] Dawid Weiss commented on LUCENE-5283: - Impl. note: - add an enum flag ifNoTests="warn|fail|ignore". - add a return property(ies) which could hold the number of executed/ ignored/ failed/ erroneous tests (separate from errorproperty and failureproperty which are already covered in standard junit target); this would allow regular ant fail and logical operators combination. > Fail the build if ant test didn't execute any tests (everything filtered out). > -- > > Key: LUCENE-5283 > URL: https://issues.apache.org/jira/browse/LUCENE-5283 > Project: Lucene - Core > Issue Type: Wish >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > > This should be an optional setting that defaults to 'false' (the build > proceeds). -- 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: Should build fail if test does not exist?
> I just wish more devs were able to help out on our test infra ... it > shouldn't have to be you always responding to our crazy feature > requests! I don't mind that at all. I am just resistant to adding things that will complicate the ant build even more than it already is... I still don't think your comparison to javac is correct. It's closer to adding a special-case exception/warning/ confirmation to "rm" command just for the particular scenario of it receiving a combination of "-rf /" arguments -- the effects are annoying, but the scenario is rare and the code mostly dead. You need to know your tools -- we should make it more explicit that these filters are glob patterns rather than hide this even deeper. And now - back to work, comrades! Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! On Oct 14, 2013 9:56 PM, "Simon Willnauer" wrote: > Welcome Ryan! > > On Mon, Oct 14, 2013 at 8:54 PM, Shawn Heisey wrote: > > On 10/14/2013 11:27 AM, Adrien Grand wrote: > >> > >> I'm pleased to announce that Ryan Ernst has accepted to join our ranks > >> as a committer. > > > > > > Congratulations and welcome! > > > > -- > > Shawn > > > > > > > > - > > 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] (SOLR-5331) SolrCloud 4.5 bulk add errors
[
https://issues.apache.org/jira/browse/SOLR-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794381#comment-13794381
]
Shawn Heisey commented on SOLR-5331:
Solr sets the servlet container's POST buffer size limit. This can be
controlled with the formdataUploadLimitInKB attribute on the requestParsers tag
in solrconfig.xml. It defaults to 2048, or 2 megabytes.
> SolrCloud 4.5 bulk add errors
> -
>
> Key: SOLR-5331
> URL: https://issues.apache.org/jira/browse/SOLR-5331
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.5
>Reporter: Chris
> Fix For: 4.5.1
>
>
> Since Solr 4.5 bulk adding documents via SolrJ (at least) is causing errors.
> // build array list of SolrInputDocuments
> server.add(docs);
> I've tried with CUSS (which swallows exceptions as expected) however they are
> shown in the logs on server, and with CloudSolrServer which is returning the
> errors as well as seeing them in the server logs.
> I've tried downgrading my SolrJ to 4.4, still errors so looks like a
> regression in the server code. Reverting to Solr 4.4 on server and I don't
> get errors (however run into deadlock issues).
> I raised this issue in IRC - NOT the mailing list, and elyorag suggested
> opening a ticket, and to mention this has now been discussed in IRC.
> The exceptions would indicate I'm attempting to do multiple operations in a
> single request which is malformed. I am not, I am only attempting to add
> documents.
> Stack traces seen here:
> 14:57:13 ERROR SolrCmdDistributor shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
>
> shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
> at [row,col {unknown-source}]: [18,327]
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:424)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:401)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:375)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
>
> org.apache.solr.common.SolrException: Illegal to have multiple roots
> (start tag in epilog?).
> at [row,col {unknown-source}]: [7,6314]
> at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:176)
> at
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! On Mon, Oct 14, 2013 at 8:54 PM, Shawn Heisey wrote: > On 10/14/2013 11:27 AM, Adrien Grand wrote: >> >> I'm pleased to announce that Ryan Ernst has accepted to join our ranks >> as a committer. > > > Congratulations and welcome! > > -- > Shawn > > > > - > 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
Re: Welcome Ryan Ernst as Lucene/Solr committer
On 10/14/2013 11:27 AM, Adrien Grand wrote: I'm pleased to announce that Ryan Ernst has accepted to join our ranks as a committer. Congratulations and welcome! -- Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5331) SolrCloud 4.5 bulk add errors
[
https://issues.apache.org/jira/browse/SOLR-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794365#comment-13794365
]
Joel Bernstein commented on SOLR-5331:
--
Thanks for the update. I was working on reproducing the bug, wasn't seeing the
error. I suspect you're right about the buffer size.
> SolrCloud 4.5 bulk add errors
> -
>
> Key: SOLR-5331
> URL: https://issues.apache.org/jira/browse/SOLR-5331
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.5
>Reporter: Chris
> Fix For: 4.5.1
>
>
> Since Solr 4.5 bulk adding documents via SolrJ (at least) is causing errors.
> // build array list of SolrInputDocuments
> server.add(docs);
> I've tried with CUSS (which swallows exceptions as expected) however they are
> shown in the logs on server, and with CloudSolrServer which is returning the
> errors as well as seeing them in the server logs.
> I've tried downgrading my SolrJ to 4.4, still errors so looks like a
> regression in the server code. Reverting to Solr 4.4 on server and I don't
> get errors (however run into deadlock issues).
> I raised this issue in IRC - NOT the mailing list, and elyorag suggested
> opening a ticket, and to mention this has now been discussed in IRC.
> The exceptions would indicate I'm attempting to do multiple operations in a
> single request which is malformed. I am not, I am only attempting to add
> documents.
> Stack traces seen here:
> 14:57:13 ERROR SolrCmdDistributor shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
>
> shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
> at [row,col {unknown-source}]: [18,327]
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:424)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:401)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:375)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
>
> org.apache.solr.common.SolrException: Illegal to have multiple roots
> (start tag in epilog?).
> at [row,col {unknown-source}]: [7,6314]
> at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:176)
> at
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
> org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:408)
> at
> org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1023)
> at
> org.apache.coyote.Abstract
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! On 14 October 2013 20:13, Ryan Ernst wrote: > Thanks Adrian. > > I grew up in Bakersfield, CA (colloquially known as "the armpit of > California"). I escaped and went to Cal Poly for my bachelors in computer > science, and after a very brief stint working on HPUX, I landed working on > the Amazon search engine for A9. I especially enjoy working with > compression and encodings, and hope to experiment there some more with > Lucene. > > Thanks > Ryan > > > On Mon, Oct 14, 2013 at 10:27 AM, Adrien Grand wrote: > >> I'm pleased to announce that Ryan Ernst has accepted to join our ranks >> as a committer. >> >> Ryan has been working on a number of Lucene and Solr issues and >> recently contributed the new expressions module[1] which allows for >> compiling javascript expressions into SortField instances with >> excellent performance since it doesn't rely on a scripting engine but >> directly generates Java bytecode. This is a very exciting change which >> will be available in Lucene 4.6. >> >> Ryan, it is tradition that you introduce yourself with a brief bio. >> >> Congratulations and welcome! >> >> [1] https://issues.apache.org/jira/browse/LUCENE-5207 >> >> -- >> Adrien >> >> - >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org >> For additional commands, e-mail: dev-h...@lucene.apache.org >> >> > -- Met vriendelijke groet, Martijn van Groningen
[jira] [Comment Edited] (SOLR-5331) SolrCloud 4.5 bulk add errors
[
https://issues.apache.org/jira/browse/SOLR-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794365#comment-13794365
]
Joel Bernstein edited comment on SOLR-5331 at 10/14/13 6:52 PM:
Thanks for the update. I was working on reproducing the bug, but wasn't seeing
the error. I suspect you're right about the buffer size.
was (Author: joel.bernstein):
Thanks for the update. I was working on reproducing the bug, wasn't seeing the
error. I suspect you're right about the buffer size.
> SolrCloud 4.5 bulk add errors
> -
>
> Key: SOLR-5331
> URL: https://issues.apache.org/jira/browse/SOLR-5331
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.5
>Reporter: Chris
> Fix For: 4.5.1
>
>
> Since Solr 4.5 bulk adding documents via SolrJ (at least) is causing errors.
> // build array list of SolrInputDocuments
> server.add(docs);
> I've tried with CUSS (which swallows exceptions as expected) however they are
> shown in the logs on server, and with CloudSolrServer which is returning the
> errors as well as seeing them in the server logs.
> I've tried downgrading my SolrJ to 4.4, still errors so looks like a
> regression in the server code. Reverting to Solr 4.4 on server and I don't
> get errors (however run into deadlock issues).
> I raised this issue in IRC - NOT the mailing list, and elyorag suggested
> opening a ticket, and to mention this has now been discussed in IRC.
> The exceptions would indicate I'm attempting to do multiple operations in a
> single request which is malformed. I am not, I am only attempting to add
> documents.
> Stack traces seen here:
> 14:57:13 ERROR SolrCmdDistributor shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
>
> shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
> at [row,col {unknown-source}]: [18,327]
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:424)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:401)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:375)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
>
> org.apache.solr.common.SolrException: Illegal to have multiple roots
> (start tag in epilog?).
> at [row,col {unknown-source}]: [7,6314]
> at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:176)
> at
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
> at
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63672 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63672/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterOutOfFileDescriptors.test Error Message: file "_e_TestBloomFilteredLucene41Postings_0.tim" already exists; siFiles=[_e.si] Stack Trace: java.lang.AssertionError: file "_e_TestBloomFilteredLucene41Postings_0.tim" already exists; siFiles=[_e.si] at __randomizedtesting.SeedInfo.seed([5DFACE3F0360D45:8D8B93395ECA60BD]:0) at org.apache.lucene.index.IndexWriter.copySegmentAsIs(IndexWriter.java:2672) at org.apache.lucene.index.IndexWriter.addIndexes(IndexWriter.java:2433) at org.apache.lucene.index.TestIndexWriterOutOfFileDescriptors.test(TestIndexWriterOutOfFileDescriptors.java:76) 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 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:722) Build Log: [...truncated 1315 lines...] [junit4] Suite: org.apache.lucene.index.TestIndexWriterOutOfFileDescriptors [junit4] 2> NOTE: reproduce with: ant test -Dtestcase=TestIndexWriterOutOfFileDescriptors -Dtests.method=test -Dtests.seed=5DFACE3F0360D45 -Dtests.slow=true -Dtests.locale=es_CL -Dtests.timezone=Asia/Beirut -Dtests.file.encoding=UT
Re: Should build fail if test does not exist?
We differ in opinions on this one, but I don't see any point in arguing -- I'll implement it, whoever wants to use it, their free will. > Net/net I think your simple solution would be great? > Really I just want a "run this exact test name, for sure!" test target. Mind you it's not exactly like that. The condition here will be "at least one test was executed"; it's still a pattern so if you make a typo that runs something then it will pass as successful. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Should build fail if test does not exist?
On Mon, Oct 14, 2013 at 2:22 PM, Dawid Weiss wrote: >> Wait, I think it is an error :) Yes, a hard to fix error (our test >> infra is complex), but still an error. > > It's a mistake in the filter declaration, not an error in its application. The difference is really an implementation detail :) I just want to run one test; that this is a 2-step process (append wildcard & apply filter, execute tests that matched that filter) ... is not important to the user. >> It's like "javac foo.java" returning successfully when foo.java doesn't >> exist. > > I don't think this is particularly matching since filters are pattern > matching. It's more like: > > grep "nonexistent" < input > > returning an error just because a pattern didn't occur in input. Well, javac foo*.java does result in an error, if no files match foo*.java. Ie javac is angry that it had nothing to compile. > Like I said -- I'm really indifferent to this, I can add it. I just > don't think we should cater for all the possible typos and errors one > can make - this would be insane. OK, thanks for opening the "wish" issue. I just wish more devs were able to help out on our test infra ... it shouldn't have to be you always responding to our crazy feature requests! 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
Re: Should build fail if test does not exist?
On Mon, Oct 14, 2013 at 2:36 PM, Michael McCandless wrote: > In fact, this would close another test trap I've hit, where I run a > single test (spelled correctly!), yet the test hit an Assume, appears > to pass (BUILD SUCCESSFUL) but actually did not run anything, I > commit, test then fails in jenkins for a stupid reason and I'm like > "WTF? I swear I tested it". > This is the complexity i dont like though. Now assume() sometimes fails the build? - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Should build fail if test does not exist?
On Mon, Oct 14, 2013 at 2:20 PM, Robert Muir wrote: > On Mon, Oct 14, 2013 at 11:11 AM, Michael McCandless > wrote: >> >> Maybe a simple compromise: could we make a new ant target, >> "run-specific-test-for-certain", whose purpose was to run that test >> and fail if no such test was not found? I think it's fine if this >> only works at the "module" level, if ant makes it too hairy to >> recurse. >> > > But is that really a compromise or will it only lead to increased > complexity? I can see how i would implement this now, > e.g. i'd just create a fileset of build/*pattern.class and fail if it > was non-empty, and then invoke 'test' target. > > But I'm worried the simple compromise would lead us down a slippery > slope, once we opened the can of worms, someone would eventually want > it to validate that you didn't typo the -Dtestmethod too right? I'm less concerned about that -- if you typo that, then all tests run, right? That becomes quickly obvious user error :) I think the other direction (BUILD SUCCESSFUL when the test did not in fact run) is much worse: it's non-obvious user error. You go away gleeful that your test passed. > And someone might be upset that my simple solution fails always if > they run clean first (since class file doesnt exist), or that it > doesnt fail if the test is @Ignored, or @Nightly and they forgot to > supply -Dtests.nightly, or @BadApples or @Slow, or throws an > assumption always because it suppresses Lucene3xCodec and you supply > -Dtests.codec=Lucene3x, or ... (it goes on and on and on). And one > could argue tehse are all traps and its trappy if we dont fix it. :) Actually I think these would be good failures, i.e. if it was a nightly test and I did not specify -Dtests.nightly then it should fail, so I know something went wrong when I tried to run "the one test". I think the restriction of "you must be in the module's directory" is acceptable. In fact, this would close another test trap I've hit, where I run a single test (spelled correctly!), yet the test hit an Assume, appears to pass (BUILD SUCCESSFUL) but actually did not run anything, I commit, test then fails in jenkins for a stupid reason and I'm like "WTF? I swear I tested it". Net/net I think your simple solution would be great? Really I just want a "run this exact test name, for sure!" test target. 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
Re: Should build fail if test does not exist?
Anyway, I filed LUCENE-5283 as a "wish". :) I'll add it in the spare cycle -- it'll work at the module level and you can override your local settings if you wish zero-test executions to fail your build. Dawid On Mon, Oct 14, 2013 at 8:22 PM, Dawid Weiss wrote: >> Wait, I think it is an error :) Yes, a hard to fix error (our test >> infra is complex), but still an error. > > It's a mistake in the filter declaration, not an error in its application. > >> It's like "javac foo.java" returning successfully when foo.java doesn't >> exist. > > I don't think this is particularly matching since filters are pattern > matching. It's more like: > > grep "nonexistent" < input > > returning an error just because a pattern didn't occur in input. > > Like I said -- I'm really indifferent to this, I can add it. I just > don't think we should cater for all the possible typos and errors one > can make - this would be insane. > > D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5348) Fail the build if ant test didn't execute any tests (everything filtered out).
Dawid Weiss created SOLR-5348: - Summary: Fail the build if ant test didn't execute any tests (everything filtered out). Key: SOLR-5348 URL: https://issues.apache.org/jira/browse/SOLR-5348 Project: Solr Issue Type: Bug Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial This should be an optional setting that defaults to 'false' (the build proceeds). -- 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-5283) Fail the build if ant test didn't execute any tests (everything filtered out).
[ https://issues.apache.org/jira/browse/LUCENE-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-5283: Issue Type: Wish (was: Bug) > Fail the build if ant test didn't execute any tests (everything filtered out). > -- > > Key: LUCENE-5283 > URL: https://issues.apache.org/jira/browse/LUCENE-5283 > Project: Lucene - Core > Issue Type: Wish >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > > This should be an optional setting that defaults to 'false' (the build > proceeds). -- 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] [Moved] (LUCENE-5283) Fail the build if ant test didn't execute any tests (everything filtered out).
[ https://issues.apache.org/jira/browse/LUCENE-5283?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss moved SOLR-5348 to LUCENE-5283: --- Key: LUCENE-5283 (was: SOLR-5348) Project: Lucene - Core (was: Solr) > Fail the build if ant test didn't execute any tests (everything filtered out). > -- > > Key: LUCENE-5283 > URL: https://issues.apache.org/jira/browse/LUCENE-5283 > Project: Lucene - Core > Issue Type: Bug >Reporter: Dawid Weiss >Assignee: Dawid Weiss >Priority: Trivial > > This should be an optional setting that defaults to 'false' (the build > proceeds). -- 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: Should build fail if test does not exist?
> Wait, I think it is an error :) Yes, a hard to fix error (our test > infra is complex), but still an error. It's a mistake in the filter declaration, not an error in its application. > It's like "javac foo.java" returning successfully when foo.java doesn't exist. I don't think this is particularly matching since filters are pattern matching. It's more like: grep "nonexistent" < input returning an error just because a pattern didn't occur in input. Like I said -- I'm really indifferent to this, I can add it. I just don't think we should cater for all the possible typos and errors one can make - this would be insane. D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Should build fail if test does not exist?
On Mon, Oct 14, 2013 at 11:11 AM, Michael McCandless wrote: > > Maybe a simple compromise: could we make a new ant target, > "run-specific-test-for-certain", whose purpose was to run that test > and fail if no such test was not found? I think it's fine if this > only works at the "module" level, if ant makes it too hairy to > recurse. > But is that really a compromise or will it only lead to increased complexity? I can see how i would implement this now, e.g. i'd just create a fileset of build/*pattern.class and fail if it was non-empty, and then invoke 'test' target. But I'm worried the simple compromise would lead us down a slippery slope, once we opened the can of worms, someone would eventually want it to validate that you didn't typo the -Dtestmethod too right? And someone might be upset that my simple solution fails always if they run clean first (since class file doesnt exist), or that it doesnt fail if the test is @Ignored, or @Nightly and they forgot to supply -Dtests.nightly, or @BadApples or @Slow, or throws an assumption always because it suppresses Lucene3xCodec and you supply -Dtests.codec=Lucene3x, or ... (it goes on and on and on). And one could argue tehse are all traps and its trappy if we dont fix it. :) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5331) SolrCloud 4.5 bulk add errors
[
https://issues.apache.org/jira/browse/SOLR-5331?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794332#comment-13794332
]
Chris commented on SOLR-5331:
-
Some updates.
I tried reducing my arraylist size check before calling server.add(docs) to 10
instead of 100, now I have no issues with my importing. Maybe there is a buffer
size, or XML length limit which I was exceeding with my (large?) posts and they
were being truncated, and causing the malformed error message?
Switching to java bin transport also solved my issue (thanks shalin) and is
faster.
> SolrCloud 4.5 bulk add errors
> -
>
> Key: SOLR-5331
> URL: https://issues.apache.org/jira/browse/SOLR-5331
> Project: Solr
> Issue Type: Bug
> Components: SolrCloud
>Affects Versions: 4.5
>Reporter: Chris
> Fix For: 4.5.1
>
>
> Since Solr 4.5 bulk adding documents via SolrJ (at least) is causing errors.
> // build array list of SolrInputDocuments
> server.add(docs);
> I've tried with CUSS (which swallows exceptions as expected) however they are
> shown in the logs on server, and with CloudSolrServer which is returning the
> errors as well as seeing them in the server logs.
> I've tried downgrading my SolrJ to 4.4, still errors so looks like a
> regression in the server code. Reverting to Solr 4.4 on server and I don't
> get errors (however run into deadlock issues).
> I raised this issue in IRC - NOT the mailing list, and elyorag suggested
> opening a ticket, and to mention this has now been discussed in IRC.
> The exceptions would indicate I'm attempting to do multiple operations in a
> single request which is malformed. I am not, I am only attempting to add
> documents.
> Stack traces seen here:
> 14:57:13 ERROR SolrCmdDistributor shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
>
> shard update error RetryNode:
> http://X.X.X.X:8080/solr/collection1_shard16_replica2/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
> Illegal to have multiple roots (start tag in epilog?).
> at [row,col {unknown-source}]: [18,327]
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:424)
> at
> org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:401)
> at
> org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:375)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:471)
> at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334)
> at java.util.concurrent.FutureTask.run(FutureTask.java:166)
> at
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:722)
>
> org.apache.solr.common.SolrException: Illegal to have multiple roots
> (start tag in epilog?).
> at [row,col {unknown-source}]: [7,6314]
> at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:176)
> at
> org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
> at
> org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
> at
> org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
> at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
> at
> org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
> at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
> at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
> at
> org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
> at
> org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
> at
> org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
> at
> org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
> at
> org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:953)
> at
> org.apache.catalina.core.StandardEngineValve.invoke(Stand
Re: Welcome Ryan Ernst as Lucene/Solr committer
Thanks Adrian. I grew up in Bakersfield, CA (colloquially known as "the armpit of California"). I escaped and went to Cal Poly for my bachelors in computer science, and after a very brief stint working on HPUX, I landed working on the Amazon search engine for A9. I especially enjoy working with compression and encodings, and hope to experiment there some more with Lucene. Thanks Ryan On Mon, Oct 14, 2013 at 10:27 AM, Adrien Grand wrote: > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > >
Re: Should build fail if test does not exist?
On Mon, Oct 14, 2013 at 12:46 PM, Dawid Weiss wrote: > This isn't an error condition (to me). Wait, I think it is an error :) Yes, a hard to fix error (our test infra is complex), but still an error. Ie, if I ask "ant test" to run a specific test, and it finds no such test, yet declares "BUILD SUCCESSFUL" in the end, how can such lenient error checking be good? It's trappy. It's like "javac foo.java" returning successfully when foo.java doesn't exist. I'm not using wildcards when I ask it to run a test :) Sure, maybe wildcards are used under the hood, but this is an implementation detail. Maybe a simple compromise: could we make a new ant target, "run-specific-test-for-certain", whose purpose was to run that test and fail if no such test was not found? I think it's fine if this only works at the "module" level, if ant makes it too hairy to recurse. 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
Re: Welcome Ryan Ernst as Lucene/Solr committer
Congrats Ryan! -Yonik On Mon, Oct 14, 2013 at 1:27 PM, Adrien Grand wrote: > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > 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
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! On Mon, Oct 14, 2013 at 10:27 AM, Adrien Grand wrote: > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > 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] (LUCENE-5274) Teach fast FastVectorHighlighter to highlight "child fields" with parent fields
[ https://issues.apache.org/jira/browse/LUCENE-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nik Everett updated LUCENE-5274: Attachment: LUCENE-5274.patch Not done yet but progress: 1. Move MergedIterator to util. 2. Add a mode to it to not remove duplicates (one extra branch per call to next). 3. Add a unit test for MergedIterator. 4. Make FieldTermStack.TermInfo, FieldPhraseList.WeighterPhraseInfo, FieldPhraseList.WeightedPhraseInfo.Toffs consistent under equals, hashCode, and compareTo. I don't think any of them would make good hash keys but I fixed up hashCode because I fixed up equals. 5. Unit tests for point 4. 7. Use the non-duplicate removing mode of MergedIterator in FieldPhraseList's merge methods. 6. More tests in FastVectorHighlighterTest - mostly around exact equal matches and how they effect segment sorting. At this point this is left: 1. Unit tests for equal matches in the same FieldPhraseList. 2. Poke around with corner cases during merges. Test them in FastVectorHighlighterTest if they reflect mockable real world cases. Expand FieldPhraseListTest if they don't. 4. Remove highlighter dependency on analyzer module. Would it make sense to move PerFieldAnalyzerWrapper into core? Something else? 3. Anything else from review. > Teach fast FastVectorHighlighter to highlight "child fields" with parent > fields > --- > > Key: LUCENE-5274 > URL: https://issues.apache.org/jira/browse/LUCENE-5274 > Project: Lucene - Core > Issue Type: Improvement > Components: core/other >Reporter: Nik Everett >Assignee: Adrien Grand >Priority: Minor > Attachments: LUCENE-5274.patch > > > I've been messing around with the FastVectorHighlighter and it looks like I > can teach it to highlight matches on "child fields". Like this query: > foo:scissors foo_exact:running > would highlight foo like this: > running with scissors > Where foo is stored WITH_POSITIONS_OFFSETS and foo_plain is an unstored copy > of foo a different analyzer and its own WITH_POSITIONS_OFFSETS. > This would make queries that perform weighted matches against different > analyzers much more convenient to highlight. > I have working code and test cases but they are hacked into Elasticsearch. > I'd love to Lucene-ify if you'll take them. -- 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-5274) Teach fast FastVectorHighlighter to highlight "child fields" with parent fields
[ https://issues.apache.org/jira/browse/LUCENE-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nik Everett updated LUCENE-5274: Attachment: (was: LUCENE-5274.patch) > Teach fast FastVectorHighlighter to highlight "child fields" with parent > fields > --- > > Key: LUCENE-5274 > URL: https://issues.apache.org/jira/browse/LUCENE-5274 > Project: Lucene - Core > Issue Type: Improvement > Components: core/other >Reporter: Nik Everett >Assignee: Adrien Grand >Priority: Minor > Attachments: LUCENE-5274.patch > > > I've been messing around with the FastVectorHighlighter and it looks like I > can teach it to highlight matches on "child fields". Like this query: > foo:scissors foo_exact:running > would highlight foo like this: > running with scissors > Where foo is stored WITH_POSITIONS_OFFSETS and foo_plain is an unstored copy > of foo a different analyzer and its own WITH_POSITIONS_OFFSETS. > This would make queries that perform weighted matches against different > analyzers much more convenient to highlight. > I have working code and test cases but they are hacked into Elasticsearch. > I'd love to Lucene-ify if you'll take them. -- 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 # 63659 - Failure!
I'll dig. Mike McCandless http://blog.mikemccandless.com On Mon, Oct 14, 2013 at 1:41 PM, wrote: > Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63659/ > > 1 tests failed. > REGRESSION: org.apache.lucene.index.TestTransactions.testTransactions > > Error Message: > > > Stack Trace: > java.lang.AssertionError > at > __randomizedtesting.SeedInfo.seed([D378017B136F4A0:CEA53CDFE5A21DA4]:0) > at org.junit.Assert.fail(Assert.java:92) > at org.junit.Assert.assertTrue(Assert.java:43) > at org.junit.Assert.assertTrue(Assert.java:54) > at > org.apache.lucene.index.TestTransactions.testTransactions(TestTransactions.java:259) > 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 > 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:722) > > > > > Build Log: > [...truncated 945 lines...] >[junit4] Suite: org.apache.lucene.index.TestTransactions >[junit4] 1> Thread[Thread-260,5,TGRP-TestTransactions]: exc >[junit4] 1> java.io.IOException: MockDirectoryWrapper: file > "_5_TestBloomFilteredLucene41Postings_0.doc"
Re: Embedded zookeeper (zkRun) - SolrPort+1000?
When I first read this I thought, "I am 99.9% sure that the ref guide and the wiki say Solr port +1000", but I checked again and both say that do in the place I was thinking of...but another place (the parameter reference) says Solr port +1001. So, +1 to fixing both sources to be consistent. I'll do it if you don't get to it. On Sat, Oct 12, 2013 at 8:03 PM, Shawn Heisey wrote: > The wiki and the ref guide both say that Solr's embedded zookeeper will > default to SolrPort+1001 ... but that would result in a typical port of > 9984. All the examples show 9983. I also checked the source code > (SolrZkServer), and it does appear to actually use +1000. > > I'm pretty sure that changing the source code to +1001 would be a bad > idea, that we actually want to update the documentation. I'm ready to > update the wiki and the ref guide, but before I do so, I would just like > to throw this out for sanity checking. Is that the correct path? > > Thanks, > Shawn > > > - > 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-5280) Rename TermFreqPayloadIterator -> SuggestionIterator
[ https://issues.apache.org/jira/browse/LUCENE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794311#comment-13794311 ] ASF subversion and git services commented on LUCENE-5280: - Commit 1532001 from [~mikemccand] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1532001 ] LUCENE-5280: rename TermFreqPayloadIterator -> InputIterator > 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 > > Attachments: LUCENE-5280.patch > > > 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] [Resolved] (LUCENE-5280) Rename TermFreqPayloadIterator -> SuggestionIterator
[ https://issues.apache.org/jira/browse/LUCENE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-5280. Resolution: Fixed Thanks Areek! > 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 > > Attachments: LUCENE-5280.patch > > > 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] [Comment Edited] (LUCENE-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794294#comment-13794294 ] Uwe Schindler edited comment on LUCENE-4956 at 10/14/13 5:46 PM: - Hi, I have seen the same code at a customer and found a big bug in FileUtils and JarResources. We should fix and replace this code completely. It's not platform independent. We should fix the following (in my opinion) horrible code parts: - FileUtils: The code with getProtectionDomain is very crazy... It also will never work if the JAR file is not a local file, but maybe some other resource. Its also using APIs that are not intended for the use-case. getProtectionDomain() is for sure not to be used to get the JAR file of the classloader. - FileUtils converts the JAR file URL (from getProtectionDomain) in a wrong way to a filesystem path: We should add URL#getPath() to the forbidden APIs, it is almost always a bug!!! The code should use toURI() and then new File(uri). The other methods in FileUtil are also having similar bugs or try to prevent them. The whole class *must* be removed, sorry! - JarResources is some crazy caching for resources and in combination with FileUtils its just wrong. Its also does not scale if you create an uber-jar. The idea of this class is to not always open a stream again, so it loads all resources of the JAR file to memory. This is the wrong way to do. Please remove this! We should remove both classes completely and load resources correctly with Class#getResourceAsStream. was (Author: thetaphi): Hi, I have seen the same code at a customer and found a big bug in FileUtils and JarResources. We should fix and replace this code completely. It's not platform independent. We should fix the following (in my opinion) horrible code parts: - FileUtils: The code with getProtectionDomain is very crazy... It also will never work if the JAR file is not a local file, but maybe some other resource. Its also using APIs that are not intended for the use-case. getProtectionDomain() is for sure not to be used to get the JAR file of the classloader. - FileUtils converts the JAR file URL (from getProtectionDomain) in a wrong way to a filesystem path: We should add URL#getPath() to the forbidden APIs, it is almost always a bug!!! The code should use toURI() and the new File(uri) - JarResources is some crazy caching for resources and in combination with FileUtils its just wrong. Its also does not scale if you create an uber-jar. The idea of this class is to not always open a stream again, so it loads all resources of the JAR file to memory. This is the wrong way to do. Please remove this! We should remove both classes completely and load resources correctly with Class#getResourceAsStream. > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: kr.analyzer.4x.tar, lucene-4956.patch, lucene4956.patch, > LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- 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: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! Mike McCandless http://blog.mikemccandless.com On Mon, Oct 14, 2013 at 1:27 PM, Adrien Grand wrote: > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > 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
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63659 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63659/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestTransactions.testTransactions Error Message: Stack Trace: java.lang.AssertionError at __randomizedtesting.SeedInfo.seed([D378017B136F4A0:CEA53CDFE5A21DA4]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.lucene.index.TestTransactions.testTransactions(TestTransactions.java:259) 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 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:722) Build Log: [...truncated 945 lines...] [junit4] Suite: org.apache.lucene.index.TestTransactions [junit4] 1> Thread[Thread-260,5,TGRP-TestTransactions]: exc [junit4] 1> java.io.IOException: MockDirectoryWrapper: file "_5_TestBloomFilteredLucene41Postings_0.doc" is still open: cannot overwrite [junit4] 1>at org.apache.lucene.store.MockDirectoryWrapper.createOutput(MockDirectoryWrapper.java:452) [junit4] 1>at org.apache.lucene.store.TrackingDirectoryWrapper.createOutput(TrackingDirectoryWrapper.java:44) [junit4] 1>
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! On Mon, Oct 14, 2013 at 10:57 PM, Adrien Grand wrote: > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > > -- Regards, Shalin Shekhar Mangar.
RE: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! Glad to have the one taking care of SolrResourceCorrumpter on board! Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de > -Original Message- > From: Adrien Grand [mailto:jpou...@gmail.com] > Sent: Monday, October 14, 2013 7:28 PM > To: dev@lucene.apache.org > Subject: Welcome Ryan Ernst as Lucene/Solr committer > > I'm pleased to announce that Ryan Ernst has accepted to join our ranks as a > committer. > > Ryan has been working on a number of Lucene and Solr issues and recently > contributed the new expressions module[1] which allows for compiling > javascript expressions into SortField instances with excellent performance > since it doesn't rely on a scripting engine but directly generates Java > bytecode. This is a very exciting change which will be available in Lucene > 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > 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
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! Alan Woodward www.flax.co.uk On 14 Oct 2013, at 18:27, Adrien Grand wrote: > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
[jira] [Commented] (LUCENE-5280) Rename TermFreqPayloadIterator -> SuggestionIterator
[ https://issues.apache.org/jira/browse/LUCENE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794301#comment-13794301 ] ASF subversion and git services commented on LUCENE-5280: - Commit 1531987 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1531987 ] LUCENE-5280: rename TermFreqPayloadIterator -> InputIterator > 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 > > Attachments: LUCENE-5280.patch > > > 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
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! On Mon, Oct 14, 2013 at 7:27 PM, Adrien Grand wrote: > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > 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
Re: Welcome Ryan Ernst as Lucene/Solr committer
Welcome Ryan! Steve On Oct 14, 2013, at 1:27 PM, Adrien Grand wrote: > I'm pleased to announce that Ryan Ernst has accepted to join our ranks > as a committer. > > Ryan has been working on a number of Lucene and Solr issues and > recently contributed the new expressions module[1] which allows for > compiling javascript expressions into SortField instances with > excellent performance since it doesn't rely on a scripting engine but > directly generates Java bytecode. This is a very exciting change which > will be available in Lucene 4.6. > > Ryan, it is tradition that you introduce yourself with a brief bio. > > Congratulations and welcome! > > [1] https://issues.apache.org/jira/browse/LUCENE-5207 > > -- > Adrien > > - > 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] (SOLR-4992) Solr queries don't propagate Java OutOfMemoryError back to the JVM
[
https://issues.apache.org/jira/browse/SOLR-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794297#comment-13794297
]
Ramkumar Aiyengar commented on SOLR-4992:
-
Doesn't `finally` offer a cleaner way to do that?
> Solr queries don't propagate Java OutOfMemoryError back to the JVM
> --
>
> Key: SOLR-4992
> URL: https://issues.apache.org/jira/browse/SOLR-4992
> Project: Solr
> Issue Type: Bug
> Components: search, SolrCloud, update
>Affects Versions: 4.3.1
>Reporter: Daniel Collins
>Assignee: Mark Miller
> Fix For: 4.6, 5.0
>
>
> Solr (specifically SolrDispatchFilter.doFilter() but there might be other
> places) handle generic java.lang.Throwable errors but that "hides"
> OutOfMemoryError scenarios.
> IndexWriter does this too but that has a specific exclusion for OOM scenarios
> and handles them explicitly (stops committing and just logs to the
> transaction log).
> {noformat}
> Example Stack trace:
> 2013-06-26 19:31:33,801 [qtp632640515-62] ERROR
> solr.servlet.SolrDispatchFilter Q:22 -
> null:java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap
> space
> at
> org.apache.solr.servlet.SolrDispatchFilter.sendError(SolrDispatchFilter.java:670)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:380)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:155)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1423)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:450)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:138)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:564)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:213)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1083)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:379)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:175)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1017)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:136)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:258)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:445)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:260)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:225)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:596)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:527)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.OutOfMemoryError: Java heap space
> {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-4956) the korean analyzer that has a korean morphological analyzer and dictionaries
[ https://issues.apache.org/jira/browse/LUCENE-4956?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794294#comment-13794294 ] Uwe Schindler commented on LUCENE-4956: --- Hi, I have seen the same code at a customer and found a big bug in FileUtils and JarResources. We should fix and replace this code completely. It's not platform independent. We should fix the following (in my opinion) horrible code parts: - FileUtils: The code with getProtectionDomain is very crazy... It also will never work if the JAR file is not a local file, but maybe some other resource. Its also using APIs that are not intended for the use-case. getProtectionDomain() is for sure not to be used to get the JAR file of the classloader. - FileUtils converts the JAR file URL (from getProtectionDomain) in a wrong way to a filesystem path: We should add URL#getPath() to the forbidden APIs, it is almost always a bug!!! The code should use toURI() and the new File(uri) - JarResources is some crazy caching for resources and in combination with FileUtils its just wrong. Its also does not scale if you create an uber-jar. The idea of this class is to not always open a stream again, so it loads all resources of the JAR file to memory. This is the wrong way to do. Please remove this! We should remove both classes completely and load resources correctly with Class#getResourceAsStream. > the korean analyzer that has a korean morphological analyzer and dictionaries > - > > Key: LUCENE-4956 > URL: https://issues.apache.org/jira/browse/LUCENE-4956 > Project: Lucene - Core > Issue Type: New Feature > Components: modules/analysis >Affects Versions: 4.2 >Reporter: SooMyung Lee >Assignee: Christian Moen > Labels: newbie > Attachments: kr.analyzer.4x.tar, lucene-4956.patch, lucene4956.patch, > LUCENE-4956.patch > > > Korean language has specific characteristic. When developing search service > with lucene & solr in korean, there are some problems in searching and > indexing. The korean analyer solved the problems with a korean morphological > anlyzer. It consists of a korean morphological analyzer, dictionaries, a > korean tokenizer and a korean filter. The korean anlyzer is made for lucene > and solr. If you develop a search service with lucene in korean, It is the > best idea to choose the korean analyzer. -- 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-4992) Solr queries don't propagate Java OutOfMemoryError back to the JVM
[
https://issues.apache.org/jira/browse/SOLR-4992?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794295#comment-13794295
]
Mark Miller commented on SOLR-4992:
---
We like to catch those throwables because of things like assertion errors - we
still want to close resources, etc.
One idea is to always do:
{code}
} catch (Throwable t) {
if (t instanceof OutOfMemoryError) {
throw (OutOfMemoryError)t;
}
{code}
But that is difficult to enforce over time.
> Solr queries don't propagate Java OutOfMemoryError back to the JVM
> --
>
> Key: SOLR-4992
> URL: https://issues.apache.org/jira/browse/SOLR-4992
> Project: Solr
> Issue Type: Bug
> Components: search, SolrCloud, update
>Affects Versions: 4.3.1
>Reporter: Daniel Collins
>Assignee: Mark Miller
> Fix For: 4.6, 5.0
>
>
> Solr (specifically SolrDispatchFilter.doFilter() but there might be other
> places) handle generic java.lang.Throwable errors but that "hides"
> OutOfMemoryError scenarios.
> IndexWriter does this too but that has a specific exclusion for OOM scenarios
> and handles them explicitly (stops committing and just logs to the
> transaction log).
> {noformat}
> Example Stack trace:
> 2013-06-26 19:31:33,801 [qtp632640515-62] ERROR
> solr.servlet.SolrDispatchFilter Q:22 -
> null:java.lang.RuntimeException: java.lang.OutOfMemoryError: Java heap
> space
> at
> org.apache.solr.servlet.SolrDispatchFilter.sendError(SolrDispatchFilter.java:670)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:380)
> at
> org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:155)
> at
> org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1423)
> at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:450)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:138)
> at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:564)
> at
> org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:213)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1083)
> at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:379)
> at
> org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:175)
> at
> org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1017)
> at
> org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:136)
> at
> org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:258)
> at
> org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:109)
> at
> org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:97)
> at org.eclipse.jetty.server.Server.handle(Server.java:445)
> at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:260)
> at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:225)
> at
> org.eclipse.jetty.io.AbstractConnection$ReadCallback.run(AbstractConnection.java:358)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:596)
> at
> org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:527)
> at java.lang.Thread.run(Thread.java:722)
> Caused by: java.lang.OutOfMemoryError: Java heap space
> {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
Welcome Ryan Ernst as Lucene/Solr committer
I'm pleased to announce that Ryan Ernst has accepted to join our ranks as a committer. Ryan has been working on a number of Lucene and Solr issues and recently contributed the new expressions module[1] which allows for compiling javascript expressions into SortField instances with excellent performance since it doesn't rely on a scripting engine but directly generates Java bytecode. This is a very exciting change which will be available in Lucene 4.6. Ryan, it is tradition that you introduce yourself with a brief bio. Congratulations and welcome! [1] https://issues.apache.org/jira/browse/LUCENE-5207 -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Should build fail if test does not exist?
Exactly. If you pass a wildcard that filters out everything then you end up without tests. This isn't an error condition (to me). I can add an option to the runner to fail on zero executed test cases but then Robert's example won't work. I don't think there is any sensible way to do it across "modules" -- aggregation would be very difficult because every ant call is pretty much isolated and doesn't know anything about the past/future. It'd be extremely hacky. If you need to filter out a test case for a particular module, cd to that module and run your tests there -- then your command line will end with the number of test cases actually run. If you're running from the top level then filtering just shouldn't fail -- it's very likely that one module or another won't contain any tests matching your filter. You can always resort to Mike's pythacks and spawn your tests from there. Dawid On Mon, Oct 14, 2013 at 5:01 PM, Robert Muir wrote: > I know understand why Dawid tried to make it clear that this stuff is > wildcard matching. > > > > > > > Its sorta like shell expansion on the unix prompt: 'echo *' shouldnt > return non-zero because there are no files in the current directory. > thats because its very general and has a lot of use cases. On the > other hand, it makes sense that 'ls *' returns 1 in this case, because > its sole purpose is listing files. > > The same can be said for your python test-repeater > > > On Mon, Oct 14, 2013 at 10:41 AM, Michael McCandless > wrote: >> This has actually bit me before too ... >> >> I mean, sure, I do eventually notice that it ran too quickly and so it >> was not in fact really SUCCESSFUL. >> >> Why would Rob's example fail? In that case, it would have in fact run >> TestIndexWriter, right? (Sure, other modules didn't have such a test, >> but the fact that one of the visited modules did have the test should >> mean that the overall ant run is SUCCESSFUL?). Is it just too hard >> with ant to make this logic be "across modules"? >> >> Mike McCandless >> >> http://blog.mikemccandless.com >> >> >> On Mon, Oct 14, 2013 at 9:41 AM, Shai Erera wrote: >>> I see, didn't think about that usecase. Ok so let's not do it. >>> >>> Shai >>> >>> >>> On Mon, Oct 14, 2013 at 4:27 PM, Robert Muir wrote: On Mon, Oct 14, 2013 at 9:11 AM, Shai Erera wrote: > > What's the harm of failing the build in that case? > because i should be able to do this and for it to pass: cd lucene/ ant test -Dtestcase=TestIndexWriter So please, don't make this change. it would totally screw everything up - 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 >> > > - > 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-5280) Rename TermFreqPayloadIterator -> SuggestionIterator
[ https://issues.apache.org/jira/browse/LUCENE-5280?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794260#comment-13794260 ] Michael McCandless commented on LUCENE-5280: Patch looks great, I'll commit shortly. Thanks Areek! > 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 > > Attachments: LUCENE-5280.patch > > > 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
Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!
> Thanks Dawid: I didn't know this was always the case. Eh... if you didn't know this too then perhaps I should have made it clearer from the beginning... So, again -- anywhere you see the "seed" in a stack trace or in a log dump or anywhere, really, it should contain the full "path" to reproduce a given failure. It is hierarchical in a way that it "locks down" the context from top to bottom -- master seed first (this also applies to static level code, beforeclass hooks, etc., then the test context (there are no nested contexts below a test). When you're reproducing you can provide the full seed: ant -Dtests.seed=[foo]:[bar] and this would lock the static- and test- scopes. Alternatively you can provide only the master: ant -Dtests.seed=[foo] and the [bar] should be inferred from the master in an identical way (a test seed is a derivative of the master, the test's name and iteration). Dawid On Sun, Oct 13, 2013 at 10:59 PM, Robert Muir wrote: > On Sun, Oct 13, 2013 at 4:46 PM, Dawid Weiss > 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 > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5268) Cutover more postings formats to the inverted "pull" API
[ https://issues.apache.org/jira/browse/LUCENE-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-5268. Resolution: Fixed > Cutover more postings formats to the inverted "pull" API > > > Key: LUCENE-5268 > URL: https://issues.apache.org/jira/browse/LUCENE-5268 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0 > > Attachments: LUCENE-5268.patch, LUCENE-5268.patch > > > In LUCENE-5123, we added a new, more flexible, "pull" API for writing > postings. This API allows the postings format to iterate the > fields/terms/postings more than once, and mirrors the API for writing > doc values. > But that was just the first step (only SimpleText was cutover to the > new API). I want to cutover more components, so we can (finally) > e.g. play with different encodings depending on the term's postings, > such as using a bitset for high freq DOCS_ONLY terms (LUCENE-5052). -- 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-5268) Cutover more postings formats to the inverted "pull" API
[ https://issues.apache.org/jira/browse/LUCENE-5268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794231#comment-13794231 ] ASF subversion and git services commented on LUCENE-5268: - Commit 1531949 from [~mikemccand] in branch 'dev/trunk' [ https://svn.apache.org/r1531949 ] LUCENE-5268: cutover all postings formats to FieldsConsumer > Cutover more postings formats to the inverted "pull" API > > > Key: LUCENE-5268 > URL: https://issues.apache.org/jira/browse/LUCENE-5268 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Michael McCandless >Assignee: Michael McCandless > Fix For: 5.0 > > Attachments: LUCENE-5268.patch, LUCENE-5268.patch > > > In LUCENE-5123, we added a new, more flexible, "pull" API for writing > postings. This API allows the postings format to iterate the > fields/terms/postings more than once, and mirrors the API for writing > doc values. > But that was just the first step (only SimpleText was cutover to the > new API). I want to cutover more components, so we can (finally) > e.g. play with different encodings depending on the term's postings, > such as using a bitset for high freq DOCS_ONLY terms (LUCENE-5052). -- 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: Should build fail if test does not exist?
On Mon, Oct 14, 2013 at 10:48 AM, Robert Muir wrote: > On Mon, Oct 14, 2013 at 10:41 AM, Michael McCandless > wrote: >> This has actually bit me before too ... >> >> I mean, sure, I do eventually notice that it ran too quickly and so it >> was not in fact really SUCCESSFUL. >> >> Why would Rob's example fail? In that case, it would have in fact run >> TestIndexWriter, right? (Sure, other modules didn't have such a test, >> but the fact that one of the visited modules did have the test should >> mean that the overall ant run is SUCCESSFUL?). Is it just too hard >> with ant to make this logic be "across modules"? >> > > 'ant test' needs to do a lot more than the specialized python script > you have to repeat one test. Right, I agree this is hard to fix, because of ant / randomizedtesting / our build scripts limitations. But I still think it's wrong that "ant test -Dtestcase=foo -Dtestmethod=bar" finishes with "BUILD SUCCESSFUL" when you have an accidental typo and in fact nothing ran. It's like javac declaring success when you mis-typed one of your java source files. I know and agree this is really, really hard for us to fix, but I still think it's wrong: it's so trappy. Maybe we need a new "ant run-this-test-for-certain" target or something. > so I think you should modify the latter instead of trying to make the > whole build system complicated. Yeah, I fixed luceneutil ... it's of course hackity, since I peek in the stdout for "OK (0 tests)" and then call that a failure. Also, luceneutil "cheats" since this particular beasting tool (repeatLuceneTest.py) only runs one module (you have to cd to that directory first). The distributed beasting tool (runRemoteTests.py) runs all modules though ... 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-5274) Teach fast FastVectorHighlighter to highlight "child fields" with parent fields
[
https://issues.apache.org/jira/browse/LUCENE-5274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794197#comment-13794197
]
Adrien Grand commented on LUCENE-5274:
--
bq. I'm not exactly sure of a good way to test the synonym stuff in
FastVectorHighlighterTest
I usually do that by building the token streams by hand, it is quite easy, see
{{CannedTokenStream}} and {{Token}} for example.
> Teach fast FastVectorHighlighter to highlight "child fields" with parent
> fields
> ---
>
> Key: LUCENE-5274
> URL: https://issues.apache.org/jira/browse/LUCENE-5274
> Project: Lucene - Core
> Issue Type: Improvement
> Components: core/other
>Reporter: Nik Everett
>Assignee: Adrien Grand
>Priority: Minor
> Attachments: LUCENE-5274.patch
>
>
> I've been messing around with the FastVectorHighlighter and it looks like I
> can teach it to highlight matches on "child fields". Like this query:
> foo:scissors foo_exact:running
> would highlight foo like this:
> running with scissors
> Where foo is stored WITH_POSITIONS_OFFSETS and foo_plain is an unstored copy
> of foo a different analyzer and its own WITH_POSITIONS_OFFSETS.
> This would make queries that perform weighted matches against different
> analyzers much more convenient to highlight.
> I have working code and test cases but they are hacked into Elasticsearch.
> I'd love to Lucene-ify if you'll take them.
--
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-5248) Improve the data structure used in ReaderAndLiveDocs to hold the updates
[ https://issues.apache.org/jira/browse/LUCENE-5248?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13794195#comment-13794195 ] Shai Erera commented on LUCENE-5248: We can even move the test to TestIWExceptions, but I think it has to be named properly .. maybe testNoLostDeletesOrUpdates, or just testNoLostUpdates? > Improve the data structure used in ReaderAndLiveDocs to hold the updates > > > Key: LUCENE-5248 > URL: https://issues.apache.org/jira/browse/LUCENE-5248 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Shai Erera >Assignee: Shai Erera > Attachments: LUCENE-5248.patch, LUCENE-5248.patch, LUCENE-5248.patch, > LUCENE-5248.patch, LUCENE-5248.patch > > > Currently ReaderAndLiveDocs holds the updates in two structures: > +Map>+ > Holds a mapping from each field, to all docs that were updated and their > values. This structure is updated when applyDeletes is called, and needs to > satisfy several requirements: > # Un-ordered writes: if a field "f" is updated by two terms, termA and termB, > in that order, and termA affects doc=100 and termB doc=2, then the updates > are applied in that order, meaning we cannot rely on updates coming in order. > # Same document may be updated multiple times, either by same term (e.g. > several calls to IW.updateNDV) or by different terms. Last update wins. > # Sequential read: when writing the updates to the Directory > (fieldsConsumer), we iterate on the docs in-order and for each one check if > it's updated and if not, pull its value from the current DV. > # A single update may affect several million documents, therefore need to be > efficient w.r.t. memory consumption. > +Map>+ > Holds a mapping from a document, to all the fields that it was updated in and > the updated value for each field. This is used by IW.commitMergedDeletes to > apply the updates that came in while the segment was merging. The > requirements this structure needs to satisfy are: > # Access in doc order: this is how commitMergedDeletes works. > # One-pass: we visit a document once (currently) and so if we can, it's > better if we know all the fields in which it was updated. The updates are > applied to the merged ReaderAndLiveDocs (where they are stored in the first > structure mentioned above). > Comments with proposals will follow next. -- 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
