[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2180 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2180/ 1 tests failed. REGRESSION: org.apache.solr.cloud.OverseerTest.testShardLeaderChange Error Message: Unexpected shard leader coll:collection1 shard:shard1 expected:core[1] but was:core[4] Stack Trace: org.junit.ComparisonFailure: Unexpected shard leader coll:collection1 shard:shard1 expected:core[1] but was:core[4] at org.junit.Assert.assertEquals(Assert.java:125) at org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:549) at org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:707) 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 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) Build Log (for compile errors): [...truncated 10403 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3318) LBHttpSolrServer should allow to specify a preferred server for a query
[ https://issues.apache.org/jira/browse/SOLR-3318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250497#comment-13250497 ] Torsten Bøgh Köster commented on SOLR-3318: --- +1 on this one. To construct a response we run 2 solr queries, one for results one for facets. For caching purpuses it would be perfect to run those consecutive one on the same solr instance LBHttpSolrServer should allow to specify a preferred server for a query --- Key: SOLR-3318 URL: https://issues.apache.org/jira/browse/SOLR-3318 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 4.0 Reporter: Martin Grotzke Priority: Minor Attachments: SOLR-3318.git.patch For a user query we make several solr queries that differ only slightly and therefore should use/reuse objects cached from the first query (we're using a custom request handler and custom caches). Thus such subsequent queries should hit the same solr server. The implemented solution looks like this: * The client obtains a live SolrServer from LBHttpSolrServer * The client provides this SolrServer as preferred server for a query * If the preferred server is no longer alive the request is retried on another live server * Everything else follows the existing logic: ** After live servers are exhausted, any servers previously marked as dead will be tried before failing the request ** If no live servers are found a SolrServerException is thrown The implementation is also [on github|https://github.com/magro/lucene-solr/commit/a75aef3d]. Mailing list thread: http://lucene.472066.n3.nabble.com/LBHttpSolrServer-to-query-a-preferred-server-tt3884140.html -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3335) testDistribSearch failure
[
https://issues.apache.org/jira/browse/SOLR-3335?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250518#comment-13250518
]
Dawid Weiss commented on SOLR-3335:
---
@Yonik: I run trunk tests in non-nightly mode and I see at least 1-2 failures a
day (runs every two hours). This does change over time though as i merge with
new commits. Some tests are frequent offenders though, like the latest one --
{noformat}
build 10-Apr-2012 00:25:25[junit] Testsuite:
org.apache.solr.cloud.OverseerTest
build 10-Apr-2012 00:25:25[junit] Testcase:
testShardLeaderChange(org.apache.solr.cloud.OverseerTest):FAILED
build 10-Apr-2012 00:25:25[junit] Unexpected shard leader
coll:collection1 shard:shard1 expected:core4 but was:null
build 10-Apr-2012 00:25:25[junit]
junit.framework.AssertionFailedError: Unexpected shard leader coll:collection1
shard:shard1 expected:core4 but was:null
build 10-Apr-2012 00:25:25[junit] at
org.junit.Assert.fail(Assert.java:93)
build 10-Apr-2012 00:25:25[junit] at
org.junit.Assert.failNotEquals(Assert.java:647)
build 10-Apr-2012 00:25:25[junit] at
org.junit.Assert.assertEquals(Assert.java:128)
build 10-Apr-2012 00:25:25[junit] at
org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:549)
build 10-Apr-2012 00:25:25[junit] at
org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:711)
build 10-Apr-2012 00:25:25[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
build 10-Apr-2012 00:25:25[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
build 10-Apr-2012 00:25:25[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
build 10-Apr-2012 00:25:25[junit] at
java.lang.reflect.Method.invoke(Method.java:597)
build 10-Apr-2012 00:25:25[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
build 10-Apr-2012 00:25:25[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
build 10-Apr-2012 00:25:25[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
build 10-Apr-2012 00:25:25[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
build 10-Apr-2012 00:25:25[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
build 10-Apr-2012 00:25:25[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
build 10-Apr-2012 00:25:25[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:63)
build 10-Apr-2012 00:25:25[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754)
build 10-Apr-2012 00:25:25[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670)
build 10-Apr-2012 00:25:25[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69)
build 10-Apr-2012 00:25:25[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:591)
build 10-Apr-2012 00:25:25[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75)
build 10-Apr-2012 00:25:25[junit] at
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642)
build 10-Apr-2012 00:25:25[junit] at
org.junit.rules.RunRules.evaluate(RunRules.java:18)
build 10-Apr-2012 00:25:25[junit] at
org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
build 10-Apr-2012 00:25:25[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
build 10-Apr-2012 00:25:25[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
build 10-Apr-2012 00:25:25[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
build 10-Apr-2012 00:25:25[junit] at
org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
build 10-Apr-2012 00:25:25[junit] at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
build 10-Apr-2012 00:25:25[junit] at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
build 10-Apr-2012 00:25:25[junit] at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
build 10-Apr-2012
Re: nightly build failures
oh, hossman fixed this already in SOLR-3335. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-3237) OverseerTest failure (non-reproducible)
[
https://issues.apache.org/jira/browse/SOLR-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren reassigned SOLR-3237:
Assignee: Sami Siren
OverseerTest failure (non-reproducible)
---
Key: SOLR-3237
URL: https://issues.apache.org/jira/browse/SOLR-3237
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Sami Siren
Priority: Minor
Fix For: 4.0
Nighly log harvest. Couldn't reproduce, unfortunately.
{noformat}
build 13-Mar-2012 06:08:43[junit] Testsuite:
org.apache.solr.cloud.OverseerTest
build 13-Mar-2012 06:08:43[junit] Testcase:
testShardLeaderChange(org.apache.solr.cloud.OverseerTest):FAILED
build 13-Mar-2012 06:08:43[junit] Unexpected shard leader
coll:collection1 shard:shard1 expected:core4 but was:null
build 13-Mar-2012 06:08:43[junit]
junit.framework.AssertionFailedError: Unexpected shard leader
coll:collection1 shard:shard1 expected:core4 but was:null
build 13-Mar-2012 06:08:43[junit] at
org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:549)
build 13-Mar-2012 06:08:43[junit] at
org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:711)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] Tests run: 7, Failures: 1, Errors:
0, Time elapsed: 74.666 sec
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] - Standard Error
-
build 13-Mar-2012 06:08:43[junit] NOTE: reproduce with: ant test
-Dtestcase=OverseerTest -Dtestmethod=testShardLeaderChange
-Dtests.seed=48c9960216b3d5d:6c1600de0df53cdd:69c37083161d807d
-Dargs=-Dfile.encoding=UTF-8
build 13-Mar-2012 06:08:43[junit] WARNING: test class left thread
running: Session Sets (4):
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:45 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:48 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:51 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:54 MST
2012:
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] RESOURCE LEAK: test class left 1
thread(s) running
build 13-Mar-2012 06:08:43[junit] NOTE: test params are:
codec=Lucene40: {}, sim=DefaultSimilarity, locale=zh_TW,
timezone=Mexico/BajaSur
build 13-Mar-2012 06:08:43[junit] NOTE: all tests run in this JVM:
build 13-Mar-2012 06:08:43[junit] [BasicFunctionalityTest,
SolrInfoMBeanTest, SnowballPorterFilterFactoryTest, TestCJKTokenizerFactory,
TestCJKWidthFilterFactory, TestChineseTokenizerFactory,
TestElisionFilterFactory, TestFinnishLightStemFilterFactory,
[jira] [Commented] (SOLR-3237) OverseerTest failure (non-reproducible)
[
https://issues.apache.org/jira/browse/SOLR-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250564#comment-13250564
]
Dawid Weiss commented on SOLR-3237:
---
I have more if you need logs, Sami. Thanks for taking care of this one!
OverseerTest failure (non-reproducible)
---
Key: SOLR-3237
URL: https://issues.apache.org/jira/browse/SOLR-3237
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Sami Siren
Priority: Minor
Fix For: 4.0
Nighly log harvest. Couldn't reproduce, unfortunately.
{noformat}
build 13-Mar-2012 06:08:43[junit] Testsuite:
org.apache.solr.cloud.OverseerTest
build 13-Mar-2012 06:08:43[junit] Testcase:
testShardLeaderChange(org.apache.solr.cloud.OverseerTest):FAILED
build 13-Mar-2012 06:08:43[junit] Unexpected shard leader
coll:collection1 shard:shard1 expected:core4 but was:null
build 13-Mar-2012 06:08:43[junit]
junit.framework.AssertionFailedError: Unexpected shard leader
coll:collection1 shard:shard1 expected:core4 but was:null
build 13-Mar-2012 06:08:43[junit] at
org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:549)
build 13-Mar-2012 06:08:43[junit] at
org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:711)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] Tests run: 7, Failures: 1, Errors:
0, Time elapsed: 74.666 sec
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] - Standard Error
-
build 13-Mar-2012 06:08:43[junit] NOTE: reproduce with: ant test
-Dtestcase=OverseerTest -Dtestmethod=testShardLeaderChange
-Dtests.seed=48c9960216b3d5d:6c1600de0df53cdd:69c37083161d807d
-Dargs=-Dfile.encoding=UTF-8
build 13-Mar-2012 06:08:43[junit] WARNING: test class left thread
running: Session Sets (4):
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:45 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:48 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:51 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:54 MST
2012:
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] RESOURCE LEAK: test class left 1
thread(s) running
build 13-Mar-2012 06:08:43[junit] NOTE: test params are:
codec=Lucene40: {}, sim=DefaultSimilarity, locale=zh_TW,
timezone=Mexico/BajaSur
build 13-Mar-2012 06:08:43[junit] NOTE: all tests run in this JVM:
build 13-Mar-2012 06:08:43[junit] [BasicFunctionalityTest,
SolrInfoMBeanTest, SnowballPorterFilterFactoryTest, TestCJKTokenizerFactory,
TestCJKWidthFilterFactory,
[jira] [Resolved] (SOLR-2020) HttpComponentsSolrServer
[ https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-2020. -- Resolution: Fixed Fix Version/s: 3.6 Assignee: Sami Siren This has been committed: 3.x r1305074, trunk r1306800 HttpComponentsSolrServer Key: SOLR-2020 URL: https://issues.apache.org/jira/browse/SOLR-2020 Project: Solr Issue Type: New Feature Components: clients - java Affects Versions: 1.4.1 Environment: Any Reporter: Chantal Ackermann Assignee: Sami Siren Priority: Minor Fix For: 3.6, 4.0 Attachments: HttpComponentsSolrServer.java, HttpComponentsSolrServerTest.java, SOLR-2020-3x.patch, SOLR-2020-HttpSolrServer.patch, SOLR-2020.patch, SOLR-2020.patch, SOLR-2020.patch, SOLR-2020.patch Implementation of SolrServer that uses the Apache Http Components framework. Http Components (http://hc.apache.org/) is the successor of Commons HttpClient and thus HttpComponentsSolrServer would be a successor of CommonsHttpSolrServer, in the future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-trunk - Build # 1889 - Failure
Build: https://builds.apache.org/job/Lucene-trunk/1889/ 1 tests failed. REGRESSION: org.apache.lucene.analysis.synonym.TestSynonymMapFilter.testRandom2GraphBefore Error Message: expected:3 but was:16 Stack Trace: junit.framework.AssertionFailedError: expected:3 but was:16 at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner$3.addError(JUnitTestRunner.java:974) at junit.framework.TestResult.addError(TestResult.java:38) at junit.framework.JUnit4TestAdapterCache$1.testFailure(JUnit4TestAdapterCache.java:51) at org.junit.runner.notification.RunNotifier$4.notifyListener(RunNotifier.java:100) at org.junit.runner.notification.RunNotifier$SafeNotifier.run(RunNotifier.java:41) at org.junit.runner.notification.RunNotifier.fireTestFailure(RunNotifier.java:97) at org.junit.internal.runners.model.EachTestNotifier.addFailure(EachTestNotifier.java:26) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:267) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) Caused by: java.lang.AssertionError: expected:3 but was:16 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:210) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:612) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:440) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:389) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:345) at org.apache.lucene.analysis.synonym.TestSynonymMapFilter.testRandom2GraphBefore(TestSynonymMapFilter.java:472) 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:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:754) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:670) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at
[jira] [Commented] (SOLR-3237) OverseerTest failure (non-reproducible)
[
https://issues.apache.org/jira/browse/SOLR-3237?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250568#comment-13250568
]
Sami Siren commented on SOLR-3237:
--
bq. I have more if you need logs...
I committed a fix to one obvious bug in the testcase, not sure if this was the
cause since in cannot easily reproduce this. I guess I'll just have to wait and
see how the stats develop in jenkins...
OverseerTest failure (non-reproducible)
---
Key: SOLR-3237
URL: https://issues.apache.org/jira/browse/SOLR-3237
Project: Solr
Issue Type: Bug
Reporter: Dawid Weiss
Assignee: Sami Siren
Priority: Minor
Fix For: 4.0
Nighly log harvest. Couldn't reproduce, unfortunately.
{noformat}
build 13-Mar-2012 06:08:43[junit] Testsuite:
org.apache.solr.cloud.OverseerTest
build 13-Mar-2012 06:08:43[junit] Testcase:
testShardLeaderChange(org.apache.solr.cloud.OverseerTest):FAILED
build 13-Mar-2012 06:08:43[junit] Unexpected shard leader
coll:collection1 shard:shard1 expected:core4 but was:null
build 13-Mar-2012 06:08:43[junit]
junit.framework.AssertionFailedError: Unexpected shard leader
coll:collection1 shard:shard1 expected:core4 but was:null
build 13-Mar-2012 06:08:43[junit] at
org.apache.solr.cloud.OverseerTest.verifyShardLeader(OverseerTest.java:549)
build 13-Mar-2012 06:08:43[junit] at
org.apache.solr.cloud.OverseerTest.testShardLeaderChange(OverseerTest.java:711)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:729)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:645)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:556)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCase$RememberThreadRule$1.evaluate(LuceneTestCase.java:618)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:20)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:51)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:21)
build 13-Mar-2012 06:08:43[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:22)
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] Tests run: 7, Failures: 1, Errors:
0, Time elapsed: 74.666 sec
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] - Standard Error
-
build 13-Mar-2012 06:08:43[junit] NOTE: reproduce with: ant test
-Dtestcase=OverseerTest -Dtestmethod=testShardLeaderChange
-Dtests.seed=48c9960216b3d5d:6c1600de0df53cdd:69c37083161d807d
-Dargs=-Dfile.encoding=UTF-8
build 13-Mar-2012 06:08:43[junit] WARNING: test class left thread
running: Session Sets (4):
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:45 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:48 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:51 MST
2012:
build 13-Mar-2012 06:08:43[junit] 0 expire at Mon Mar 12 22:08:54 MST
2012:
build 13-Mar-2012 06:08:43[junit]
build 13-Mar-2012 06:08:43[junit] RESOURCE LEAK: test class left 1
thread(s) running
build 13-Mar-2012 06:08:43[junit] NOTE: test params are:
codec=Lucene40: {}, sim=DefaultSimilarity, locale=zh_TW,
timezone=Mexico/BajaSur
build 13-Mar-2012 06:08:43[junit] NOTE: all tests run in this JVM:
build
Re: VOTE: Lucene/Solr 3.6 (take two)
+1. New all source packages look good and the Ivy stuff worked. Sigs check out. On Apr 6, 2012, at 1:27 PM, Robert Muir wrote: Artifacts here: http://s.apache.org/lusolr36rc1 I tested with smoketester, (including newly added checks), so here is my +1. Note: smoketester currently does not support windows (use a linux system) -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] branch-3x Build # 1334053561 - Failure
Build failure running tests You can see the entire build log at http://sierranevada.servebeer.com/1334053561.log Summary of tests that failed... ./solr/build/solr-solrj/test/TEST-org.apache.solr.common.util.ContentStreamTest.xml Thanks, Charlie Cron (version 2.0-hossman-patched) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: Lucene/Solr 3.6 (take two)
+1 - all of my typical tinkerings worked fine. On Apr 6, 2012, at 13:27 , Robert Muir wrote: Artifacts here: http://s.apache.org/lusolr36rc1 I tested with smoketester, (including newly added checks), so here is my +1. Note: smoketester currently does not support windows (use a linux system) -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
POM dependencies not all there yet for solr-test-framework
--
Key: SOLR-3344
URL: https://issues.apache.org/jira/browse/SOLR-3344
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Benson Margulies
The pom for solr-test-framework does not mention jetty, so a test case that
doesn't get jetty into it's classpath otherwise fails with:
{noformat}
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benson Margulies updated SOLR-3344:
---
Attachment: 0001-Add-jetty-deps.patch
Here's the fix.
POM dependencies not all there yet for solr-test-framework
--
Key: SOLR-3344
URL: https://issues.apache.org/jira/browse/SOLR-3344
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Benson Margulies
Attachments: 0001-Add-jetty-deps.patch
The pom for solr-test-framework does not mention jetty, so a test case that
doesn't get jetty into it's classpath otherwise fails with:
{noformat}
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 13007 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13007/ 1 tests failed. REGRESSION: org.apache.lucene.analysis.synonym.TestSynonymMapFilter.testRandom2GraphBefore Error Message: Uncaught exception by thread: Thread[Thread-742,5,] Stack Trace: org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread: Uncaught exception by thread: Thread[Thread-742,5,] at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:84) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) Caused by: java.lang.AssertionError: expected:9 but was:17 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:210) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:612) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:440) at org.apache.lucene.analysis.BaseTokenStreamTestCase.access$000(BaseTokenStreamTestCase.java:53) at org.apache.lucene.analysis.BaseTokenStreamTestCase$AnalysisThread.run(BaseTokenStreamTestCase.java:381) Build Log (for compile errors): [...truncated 3513 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3345) BaseDistributedSearchTestCase should always ignore QTime
BaseDistributedSearchTestCase should always ignore QTime Key: SOLR-3345 URL: https://issues.apache.org/jira/browse/SOLR-3345 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Reporter: Benson Margulies The existing subclasses of BaseDistributedSearchTestCase all skip QTime. I can't see any way in which those numbers will ever match. Why not make this the default, or only, behavior? (This is really a question, in that I will provide a patch if no one tells me that it is a bad idea.) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250649#comment-13250649
]
Steven Rowe commented on SOLR-3344:
---
Benson, where are you seeing these failures? Why hasn't Jenkins unearthed them?
Why should Solr test-framework declare these dependencies at all? That is, why
can't modules with Jetty test dependencies simply declare the dependency there
(with scope=test)? This is already the case for the following Solr modules:
solr-core, clustering, and dataimporthandler.
If it does turn out that Solr test-framework is the right place for these
dependencies, it doesn't require Jetty to compile, so at a minimum, I would
argue that the default compile scope you've used is inappropriate. Maybe
scope=runtime?
POM dependencies not all there yet for solr-test-framework
--
Key: SOLR-3344
URL: https://issues.apache.org/jira/browse/SOLR-3344
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Benson Margulies
Attachments: 0001-Add-jetty-deps.patch
The pom for solr-test-framework does not mention jetty, so a test case that
doesn't get jetty into it's classpath otherwise fails with:
{noformat}
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: Lucene/Solr 3.6 (take two)
+1 On Fri, Apr 6, 2012 at 10:57 PM, Robert Muir rcm...@gmail.com wrote: Artifacts here: http://s.apache.org/lusolr36rc1 I tested with smoketester, (including newly added checks), so here is my +1. Note: smoketester currently does not support windows (use a linux system) -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Regards, Shalin Shekhar Mangar.
Distributed Pivot Faceting patch for SOLR-2894
Hi, I submitted a patch for distributed pivot faceting on this issue https://issues.apache.org/jira/browse/SOLR-2894 about a month ago. Currently this issue is unassigned and has no fix version so it hasn't been picked up by anybody yet. I was wondering if someone has time to look at this and commit it to trunk for Solr 4.0. It's unit tested and my company have been running it with a dev version of Solr 4.0 successfully for some time now. The patch I submitted shouldn't affect any other functionality so it should be safe to put it into trunk and let people try it out. I'm happy to help out with any further bug fixes required for this, any improvements I can make will obviously benefit us as well. Also if someone does take the time to look at the patch and it needs amending or updating before it can be used I can do that too. Regards, Dan Cooper. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: VOTE: Lucene/Solr 3.6 (take two)
+1 -Yonik lucenerevolution.com - Lucene/Solr Open Source Search Conference. Boston May 7-10 On Fri, Apr 6, 2012 at 1:27 PM, Robert Muir rcm...@gmail.com wrote: Artifacts here: http://s.apache.org/lusolr36rc1 I tested with smoketester, (including newly added checks), so here is my +1. Note: smoketester currently does not support windows (use a linux system) -- lucidimagination.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-2894: -- Affects Version/s: (was: 4.0) Fix Version/s: 4.0 Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.0 Attachments: SOLR-2894.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250716#comment-13250716
]
Benson Margulies commented on SOLR-3344:
Here's how this plays out.
In my very own project, not in the lucene tree anywhere, I wrote a test class
that uses the base class for distributed tests. So I put the test-framework in
as a scopetest/scope dependency.
It compiles fine, but gets NoClassDefFound for Jetty when I run it. Why? Well,
jetty is listed as an *optional* dependency of solr-core. So it is not
transitive.
I think that it's reasonable for the test framework jar to list it as a
required dependency, since tests in there depend on it. However, there is an
alternative (other than nothing): list it again as an optional dependency in
test-framework, just to give people a hint, and/or change the javadoc for the
BaseDistributedTestCase to note this requirement.
POM dependencies not all there yet for solr-test-framework
--
Key: SOLR-3344
URL: https://issues.apache.org/jira/browse/SOLR-3344
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Benson Margulies
Attachments: 0001-Add-jetty-deps.patch
The pom for solr-test-framework does not mention jetty, so a test case that
doesn't get jetty into it's classpath otherwise fails with:
{noformat}
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3346) qt Dispatching Request Handler
qt Dispatching Request Handler -- Key: SOLR-3346 URL: https://issues.apache.org/jira/browse/SOLR-3346 Project: Solr Issue Type: New Feature Components: search Reporter: David Smiley Fix For: 4.0 Instead of 'qt' being handled by the SolrDispatchFilter (a Servlet Filter), it would be better implemented as a request handler, with a suggested name of DispatchingRequestHandler. This is better because: * it keeps the servlet filter more focused / simplified (albeit just a little) * it simplifies solrconfig.xml by removing/deprecating handleSelect=true. 'qt' is less magic, it works more explicitly. * if you don't want to use 'qt' dispatch, simply don't use DispatchingRequestHandler * DispatchingRequestHandler would get used by EmbeddedSolrServer but SolrDispatchFilter is not. Credit: Hoss's idea, Erik coded a first draft -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250733#comment-13250733
]
Steven Rowe commented on SOLR-3344:
---
bq. I think that it's reasonable for the test framework jar to list it as a
required dependency, since tests in there depend on it. However, there is an
alternative (other than nothing): list it again as an optional dependency in
test-framework, just to give people a hint, and/or change the javadoc for the
BaseDistributedTestCase to note this requirement.
I assume you're referring to {{BaseDistributed*Search*TestCase}}, which depends
on solr-core's {{oas.client.solrj.embedded.JettySolrRunner}}?
I like the optional dependencies alternative better: add optional jetty
dependencies to Solr test-framework, and change the javadoc for
BaseDistributedSearchTestCase to note this requirement.
POM dependencies not all there yet for solr-test-framework
--
Key: SOLR-3344
URL: https://issues.apache.org/jira/browse/SOLR-3344
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Benson Margulies
Attachments: 0001-Add-jetty-deps.patch
The pom for solr-test-framework does not mention jetty, so a test case that
doesn't get jetty into it's classpath otherwise fails with:
{noformat}
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3346) qt Dispatching Request Handler
[ https://issues.apache.org/jira/browse/SOLR-3346?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250742#comment-13250742 ] Yonik Seeley commented on SOLR-3346: I think I would prefer leaving things as they are (as you say, it's just a small piece of code in the SolrDispatchFilter... and qt is all about dispatching!) It would seem to introduce extra overhead for anyone that wanted to use qt as they did before, and there's a good probability that it would introduce more bugs as well. qt Dispatching Request Handler -- Key: SOLR-3346 URL: https://issues.apache.org/jira/browse/SOLR-3346 Project: Solr Issue Type: New Feature Components: search Reporter: David Smiley Fix For: 4.0 Instead of 'qt' being handled by the SolrDispatchFilter (a Servlet Filter), it would be better implemented as a request handler, with a suggested name of DispatchingRequestHandler. This is better because: * it keeps the servlet filter more focused / simplified (albeit just a little) * it simplifies solrconfig.xml by removing/deprecating handleSelect=true. 'qt' is less magic, it works more explicitly. * if you don't want to use 'qt' dispatch, simply don't use DispatchingRequestHandler * DispatchingRequestHandler would get used by EmbeddedSolrServer but SolrDispatchFilter is not. Credit: Hoss's idea, Erik coded a first draft -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3282) Perform Kuromoji/Japanese stability test before 3.6 freeze
[
https://issues.apache.org/jira/browse/SOLR-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250751#comment-13250751
]
Christian Moen commented on SOLR-3282:
--
I'll resolve this issue now.
I've also been doing additional testing using the VisualVM Visual GC plugin and
I'm seeing that the {{org.apache.lucene.analysis.ja.Token}} objects gets
collected fairly as we expect. In actual deployments, it's perhaps a good idea
to use a larger eden space by using the server GC defaults or tune things up.
In longer term tests, it seems like Solr's heap-space is being used also in the
case of a 512MB heap before a full GC recovered lots of heap. I suspect this
might be caused by searching with highlighting and the heap seems very stable
with indexing only. (In either case, this doesn't seem to be caused by
Kuromoji.)
Perform Kuromoji/Japanese stability test before 3.6 freeze
--
Key: SOLR-3282
URL: https://issues.apache.org/jira/browse/SOLR-3282
Project: Solr
Issue Type: Task
Components: Schema and Analysis
Affects Versions: 3.6, 4.0
Reporter: Christian Moen
Assignee: Christian Moen
Attachments: 250k-queries-no-highlight-gc.log,
250k-queries-no-highlight-visualvm.png, 62k-queries-highlight-gc.log,
62k-queries-highlight-visualvm.png, jawiki-index-gc.log,
jawiki-index-gcviewer.png, jawiki-index-visualvm.png,
long-query-indexing-gc.log, long-search-indexing-visualvm.png
Kuromoji might be used by many and also in mission critical systems. I'd
like to run a stability test before we freeze 3.6.
My thinking is to test the out-of-the-box configuration using fieldtype
{{text_ja}} as follows:
# Index all of Japanese Wikipedia documents (approx. 1.4M documents) in a
never ending loop
# Simultaneously run many tens of thousands typical Japanese queries against
the index at 3-5 queries per second with highlighting turned on
While Solr is indexing and searching, I'd like to verify that:
* Indexing and queries are working as expected
* Memory and heap usage looks stable over time
* Garbage collection is overall low over time -- no Full-GC issues
I'll post findings and results to this JIRA.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250753#comment-13250753
]
Steven Rowe commented on SOLR-3344:
---
bq. I like the optional dependencies alternative better: add optional jetty
dependencies to Solr test-framework, and change the javadoc for
BaseDistributedSearchTestCase to note this requirement.
Thinking about this more, the rationale I would ordinarily use to justify
making a dependency optional involves minimizing *runtime* dependencies. But
the Solr test-framework is a test-only module, and requiring *test*
dependencies that won't be used by all consumers should not cause any undue
hardship.
So I've changed my mind. I'll put up a superset of your patch, Benson, that
removes the dataimporthandler and clustering POMs' jetty dependencies. I'll
leave solr-core's optional dependency as-is.
POM dependencies not all there yet for solr-test-framework
--
Key: SOLR-3344
URL: https://issues.apache.org/jira/browse/SOLR-3344
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Benson Margulies
Attachments: 0001-Add-jetty-deps.patch
The pom for solr-test-framework does not mention jetty, so a test case that
doesn't get jetty into it's classpath otherwise fails with:
{noformat}
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250757#comment-13250757
]
Benson Margulies commented on SOLR-3344:
Thank you very much.
POM dependencies not all there yet for solr-test-framework
--
Key: SOLR-3344
URL: https://issues.apache.org/jira/browse/SOLR-3344
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Benson Margulies
Attachments: 0001-Add-jetty-deps.patch
The pom for solr-test-framework does not mention jetty, so a test case that
doesn't get jetty into it's classpath otherwise fails with:
{noformat}
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Web site and mailing lists
: On http://lucene.apache.org/core/discussion.html, : : there is a link at the bottom that purports to point to a different : page with a longer list of mailing lists. : : http://lucene.apache.org/mail.html : : However, that link points right back to the page I found it on. : Further, I can't find any page that just has a complete list of all : the TLP's mailing lists. thanks for catching that. we've never had a page that lists all the mailing lists ... it might make more sense then the way the pages are currently split out... http://lucene.staging.apache.org/core/discussion.html http://lucene.staging.apache.org/solr/discussion.html ...but personally i think it would be better to make all of those pages more focused on lists for *users* and break dev (and dev related lists) out to a whole new section of the site. in any case: i fixed that circular link you mentioned and put info about general@lucene on those two pages. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Web site and mailing lists
Thanks. On Tue, Apr 10, 2012 at 12:44 PM, Chris Hostetter hossman_luc...@fucit.org wrote: : On http://lucene.apache.org/core/discussion.html, : : there is a link at the bottom that purports to point to a different : page with a longer list of mailing lists. : : http://lucene.apache.org/mail.html : : However, that link points right back to the page I found it on. : Further, I can't find any page that just has a complete list of all : the TLP's mailing lists. thanks for catching that. we've never had a page that lists all the mailing lists ... it might make more sense then the way the pages are currently split out... http://lucene.staging.apache.org/core/discussion.html http://lucene.staging.apache.org/solr/discussion.html ...but personally i think it would be better to make all of those pages more focused on lists for *users* and break dev (and dev related lists) out to a whole new section of the site. in any case: i fixed that circular link you mentioned and put info about general@lucene on those two pages. -Hoss - 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] (SOLR-3282) Perform Kuromoji/Japanese stability test before 3.6 freeze
[
https://issues.apache.org/jira/browse/SOLR-3282?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Christian Moen resolved SOLR-3282.
--
Resolution: Fixed
Perform Kuromoji/Japanese stability test before 3.6 freeze
--
Key: SOLR-3282
URL: https://issues.apache.org/jira/browse/SOLR-3282
Project: Solr
Issue Type: Task
Components: Schema and Analysis
Affects Versions: 3.6, 4.0
Reporter: Christian Moen
Assignee: Christian Moen
Attachments: 250k-queries-no-highlight-gc.log,
250k-queries-no-highlight-visualvm.png, 62k-queries-highlight-gc.log,
62k-queries-highlight-visualvm.png, jawiki-index-gc.log,
jawiki-index-gcviewer.png, jawiki-index-visualvm.png,
long-query-indexing-gc.log, long-search-indexing-visualvm.png
Kuromoji might be used by many and also in mission critical systems. I'd
like to run a stability test before we freeze 3.6.
My thinking is to test the out-of-the-box configuration using fieldtype
{{text_ja}} as follows:
# Index all of Japanese Wikipedia documents (approx. 1.4M documents) in a
never ending loop
# Simultaneously run many tens of thousands typical Japanese queries against
the index at 3-5 queries per second with highlighting turned on
While Solr is indexing and searching, I'd like to verify that:
* Indexing and queries are working as expected
* Memory and heap usage looks stable over time
* Garbage collection is overall low over time -- no Full-GC issues
I'll post findings and results to this JIRA.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated SOLR-3344:
--
Attachment: SOLR-3344.patch
Patch, adding 3 required Jetty dependencies to the Solr test-framework POM
template, and removing those dependencies from the dataimporthandler and
clustering POM templates.
Tests all pass for me locally.
Committing shortly.
POM dependencies not all there yet for solr-test-framework
--
Key: SOLR-3344
URL: https://issues.apache.org/jira/browse/SOLR-3344
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Benson Margulies
Attachments: 0001-Add-jetty-deps.patch, SOLR-3344.patch
The pom for solr-test-framework does not mention jetty, so a test case that
doesn't get jetty into it's classpath otherwise fails with:
{noformat}
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250910#comment-13250910 ] Hoss Man commented on SOLR-3076: As i said before... bq. ...perhaps we should focus on the more user explicit, direct mapping type QParser type approach Mikhail has already started on for now, and consider that (_schema driven implicit block joining_) as an enhancement later? (especially since it's not clear how the indexing side will be managed/enforced...) what Mikhail's fleshed out here seems like a good starting point for users who are willing to deal with this at the low level (similar in expertness to the raw QParser) , and would be usable *today* for people who take responsibility of indexing the blocks themselves. if/when/how we decide to drive the indexing side, we can think about how if/where/how to automagically hook blockjoin queries into higher level parsers like LuceneQParser, DismaxQueryParser Solr should support block joins --- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Attachments: SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, parent-bjq-qparser.patch, parent-bjq-qparser.patch, solrconf-bjq-erschema-snippet.xml, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe resolved SOLR-3344.
---
Resolution: Fixed
Fix Version/s: 4.0
Assignee: Steven Rowe
Committed to trunk: r1311905.
POM dependencies not all there yet for solr-test-framework
--
Key: SOLR-3344
URL: https://issues.apache.org/jira/browse/SOLR-3344
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Benson Margulies
Assignee: Steven Rowe
Fix For: 4.0
Attachments: 0001-Add-jetty-deps.patch, SOLR-3344.patch
The pom for solr-test-framework does not mention jetty, so a test case that
doesn't get jetty into it's classpath otherwise fails with:
{noformat}
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe reopened SOLR-3344:
---
bq. If it does turn out that Solr test-framework is the right place for these
dependencies, it doesn't require Jetty to compile, so at a minimum, I would
argue that the default compile scope you've used is inappropriate. Maybe
scope=runtime?
I forgot to incorporate this change - reopening to change Solr test-framework's
Jetty dependencies' scope from compile to runtime.
POM dependencies not all there yet for solr-test-framework
--
Key: SOLR-3344
URL: https://issues.apache.org/jira/browse/SOLR-3344
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Benson Margulies
Assignee: Steven Rowe
Fix For: 4.0
Attachments: 0001-Add-jetty-deps.patch, SOLR-3344.patch
The pom for solr-test-framework does not mention jetty, so a test case that
doesn't get jetty into it's classpath otherwise fails with:
{noformat}
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1311920 - /lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/apache/lucene/analysis/core/TestRandomChains.java
Sorry Uwe :)
I guess Emacs indents differently from Eclipse!
Mike McCandless
http://blog.mikemccandless.com
On Tue, Apr 10, 2012 at 2:50 PM, uschind...@apache.org wrote:
Author: uschindler
Date: Tue Apr 10 18:50:54 2012
New Revision: 1311920
URL: http://svn.apache.org/viewvc?rev=1311920view=rev
Log:
LUCENE-3969: revert Whitespace
Modified:
lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/apache/lucene/analysis/core/TestRandomChains.java
Modified:
lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/apache/lucene/analysis/core/TestRandomChains.java
URL:
http://svn.apache.org/viewvc/lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/apache/lucene/analysis/core/TestRandomChains.java?rev=1311920r1=1311919r2=1311920view=diff
==
---
lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/apache/lucene/analysis/core/TestRandomChains.java
(original)
+++
lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/apache/lucene/analysis/core/TestRandomChains.java
Tue Apr 10 18:50:54 2012
@@ -105,30 +105,30 @@ public class TestRandomChains extends Ba
// nocommit can we promote some of these to be only
// offsets offenders?
Collections.Class?addAll(brokenComponents,
- // TODO: fix basetokenstreamtestcase not to
trip because this one has no CharTermAtt
- EmptyTokenizer.class,
- // doesn't actual reset itself!
- CachingTokenFilter.class,
- // doesn't consume whole stream!
- LimitTokenCountFilter.class,
- // Not broken: we forcefully add this, so
we shouldn't
- // also randomly pick it:
- ValidatingTokenFilter.class,
- // NOTE: these by themselves won't cause
any 'basic assertions' to fail.
- // but see
https://issues.apache.org/jira/browse/LUCENE-3920, if any
- // tokenfilter that combines words (e.g.
shingles) comes after them,
- // this will create bogus offsets because
their 'offsets go backwards',
- // causing shingle or whatever to make a
single token with a
- // startOffset thats its endOffset
- // (see LUCENE-3738 for a list of other
offenders here)
- // broken!
- NGramTokenizer.class,
- // broken!
- NGramTokenFilter.class,
- // broken!
- EdgeNGramTokenizer.class,
- // broken!
- EdgeNGramTokenFilter.class
+ // TODO: fix basetokenstreamtestcase not to trip because this one has
no CharTermAtt
+ EmptyTokenizer.class,
+ // doesn't actual reset itself!
+ CachingTokenFilter.class,
+ // doesn't consume whole stream!
+ LimitTokenCountFilter.class,
+ // Not broken: we forcefully add this, so we shouldn't
+ // also randomly pick it:
+ ValidatingTokenFilter.class,
+ // NOTE: these by themselves won't cause any 'basic assertions' to
fail.
+ // but see https://issues.apache.org/jira/browse/LUCENE-3920, if any
+ // tokenfilter that combines words (e.g. shingles) comes after them,
+ // this will create bogus offsets because their 'offsets go backwards',
+ // causing shingle or whatever to make a single token with a
+ // startOffset thats its endOffset
+ // (see LUCENE-3738 for a list of other offenders here)
+ // broken!
+ NGramTokenizer.class,
+ // broken!
+ NGramTokenFilter.class,
+ // broken!
+ EdgeNGramTokenizer.class,
+ // broken!
+ EdgeNGramTokenFilter.class
);
}
@@ -137,18 +137,19 @@ public class TestRandomChains extends Ba
private static final SetClass? brokenOffsetsComponents =
Collections.newSetFromMap(new IdentityHashMapClass?,Boolean());
static {
Collections.Class?addAll(brokenOffsetsComponents,
- WordDelimiterFilter.class,
- TrimFilter.class,
- ReversePathHierarchyTokenizer.class,
- PathHierarchyTokenizer.class,
- HyphenationCompoundWordTokenFilter.class,
- DictionaryCompoundWordTokenFilter.class,
- // nocommit: corrumpts graphs
RE: svn commit: r1311920 - /lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/apache/lucene/analysis/core/TestRandomChains.java
No problem, I mainly readded the missing newlines between methods. The other indenting was not so important, but it took too much space to the right. Why does Emacs change the indenting of unrelated code? My favorite Notepad++ (or Eclipse if I also do refactoring) only does this on the block you are working on! It seems your Emacs sometimes changes the whole file formatting? Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Tuesday, April 10, 2012 9:01 PM To: dev@lucene.apache.org Subject: Re: svn commit: r1311920 - /lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/apa che/lucene/analysis/core/TestRandomChains.java Sorry Uwe :) I guess Emacs indents differently from Eclipse! Mike McCandless http://blog.mikemccandless.com On Tue, Apr 10, 2012 at 2:50 PM, uschind...@apache.org wrote: Author: uschindler Date: Tue Apr 10 18:50:54 2012 New Revision: 1311920 URL: http://svn.apache.org/viewvc?rev=1311920view=rev Log: LUCENE-3969: revert Whitespace Modified: lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/ap ache/lucene/analysis/core/TestRandomChains.java Modified: lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/ap ache/lucene/analysis/core/TestRandomChains.java URL: http://svn.apache.org/viewvc/lucene/dev/branches/lucene3969/modules/an alysis/common/src/test/org/apache/lucene/analysis/core/TestRandomChain s.java?rev=1311920r1=1311919r2=1311920view=diff == --- lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/ap ache/lucene/analysis/core/TestRandomChains.java (original) +++ lucene/dev/branches/lucene3969/modules/analysis/common/src/test/or +++ g/apache/lucene/analysis/core/TestRandomChains.java Tue Apr 10 +++ 18:50:54 2012 @@ -105,30 +105,30 @@ public class TestRandomChains extends Ba // nocommit can we promote some of these to be only // offsets offenders? Collections.Class?addAll(brokenComponents, - // TODO: fix basetokenstreamtestcase not to trip because this one has no CharTermAtt - EmptyTokenizer.class, - // doesn't actual reset itself! - CachingTokenFilter.class, - // doesn't consume whole stream! - LimitTokenCountFilter.class, - // Not broken: we forcefully add this, so we shouldn't - // also randomly pick it: - ValidatingTokenFilter.class, - // NOTE: these by themselves won't cause any 'basic assertions' to fail. - // but see https://issues.apache.org/jira/browse/LUCENE-3920, if any - // tokenfilter that combines words (e.g. shingles) comes after them, - // this will create bogus offsets because their 'offsets go backwards', - // causing shingle or whatever to make a single token with a - // startOffset thats its endOffset - // (see LUCENE-3738 for a list of other offenders here) - // broken! - NGramTokenizer.class, - // broken! - NGramTokenFilter.class, - // broken! - EdgeNGramTokenizer.class, - // broken! - EdgeNGramTokenFilter.class + // TODO: fix basetokenstreamtestcase not to trip because this + one has no CharTermAtt + EmptyTokenizer.class, + // doesn't actual reset itself! + CachingTokenFilter.class, + // doesn't consume whole stream! + LimitTokenCountFilter.class, + // Not broken: we forcefully add this, so we shouldn't + // also randomly pick it: + ValidatingTokenFilter.class, + // NOTE: these by themselves won't cause any 'basic assertions' to fail. + // but see https://issues.apache.org/jira/browse/LUCENE-3920, + if any + // tokenfilter that combines words (e.g. shingles) comes after + them, + // this will create bogus offsets because their 'offsets go + backwards', + // causing shingle or whatever to make a single token with a + // startOffset thats its endOffset + // (see LUCENE-3738 for a list of other offenders here) + // broken! +
Re: [JENKINS] Lucene-Solr-tests-only-trunk - Build # 13007 - Failure
I committed a fix (commented out this test). SynFilter can't yet consume graphs... Mike McCandless http://blog.mikemccandless.com On Tue, Apr 10, 2012 at 8:06 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13007/ 1 tests failed. REGRESSION: org.apache.lucene.analysis.synonym.TestSynonymMapFilter.testRandom2GraphBefore Error Message: Uncaught exception by thread: Thread[Thread-742,5,] Stack Trace: org.apache.lucene.util.UncaughtExceptionsRule$UncaughtExceptionsInBackgroundThread: Uncaught exception by thread: Thread[Thread-742,5,] at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:84) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:642) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:164) at org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:57) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:39) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:743) Caused by: java.lang.AssertionError: expected:9 but was:17 at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.lucene.analysis.BaseTokenStreamTestCase.assertTokenStreamContents(BaseTokenStreamTestCase.java:210) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:612) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:440) at org.apache.lucene.analysis.BaseTokenStreamTestCase.access$000(BaseTokenStreamTestCase.java:53) at org.apache.lucene.analysis.BaseTokenStreamTestCase$AnalysisThread.run(BaseTokenStreamTestCase.java:381) Build Log (for compile errors): [...truncated 3513 lines...] - 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: svn commit: r1311920 - /lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/apache/lucene/analysis/core/TestRandomChains.java
That's because emacs (and vim) indent blocks of code you haven't thought about yet, but will think about in 5 minutes from a given time... Dawid On Tue, Apr 10, 2012 at 9:07 PM, Uwe Schindler u...@thetaphi.de wrote: No problem, I mainly readded the missing newlines between methods. The other indenting was not so important, but it took too much space to the right. Why does Emacs change the indenting of unrelated code? My favorite Notepad++ (or Eclipse if I also do refactoring) only does this on the block you are working on! It seems your Emacs sometimes changes the whole file formatting? Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Michael McCandless [mailto:luc...@mikemccandless.com] Sent: Tuesday, April 10, 2012 9:01 PM To: dev@lucene.apache.org Subject: Re: svn commit: r1311920 - /lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/apa che/lucene/analysis/core/TestRandomChains.java Sorry Uwe :) I guess Emacs indents differently from Eclipse! Mike McCandless http://blog.mikemccandless.com On Tue, Apr 10, 2012 at 2:50 PM, uschind...@apache.org wrote: Author: uschindler Date: Tue Apr 10 18:50:54 2012 New Revision: 1311920 URL: http://svn.apache.org/viewvc?rev=1311920view=rev Log: LUCENE-3969: revert Whitespace Modified: lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/ap ache/lucene/analysis/core/TestRandomChains.java Modified: lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/ap ache/lucene/analysis/core/TestRandomChains.java URL: http://svn.apache.org/viewvc/lucene/dev/branches/lucene3969/modules/an alysis/common/src/test/org/apache/lucene/analysis/core/TestRandomChain s.java?rev=1311920r1=1311919r2=1311920view=diff == --- lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/ap ache/lucene/analysis/core/TestRandomChains.java (original) +++ lucene/dev/branches/lucene3969/modules/analysis/common/src/test/or +++ g/apache/lucene/analysis/core/TestRandomChains.java Tue Apr 10 +++ 18:50:54 2012 @@ -105,30 +105,30 @@ public class TestRandomChains extends Ba // nocommit can we promote some of these to be only // offsets offenders? Collections.Class?addAll(brokenComponents, - // TODO: fix basetokenstreamtestcase not to trip because this one has no CharTermAtt - EmptyTokenizer.class, - // doesn't actual reset itself! - CachingTokenFilter.class, - // doesn't consume whole stream! - LimitTokenCountFilter.class, - // Not broken: we forcefully add this, so we shouldn't - // also randomly pick it: - ValidatingTokenFilter.class, - // NOTE: these by themselves won't cause any 'basic assertions' to fail. - // but see https://issues.apache.org/jira/browse/LUCENE-3920, if any - // tokenfilter that combines words (e.g. shingles) comes after them, - // this will create bogus offsets because their 'offsets go backwards', - // causing shingle or whatever to make a single token with a - // startOffset thats its endOffset - // (see LUCENE-3738 for a list of other offenders here) - // broken! - NGramTokenizer.class, - // broken! - NGramTokenFilter.class, - // broken! - EdgeNGramTokenizer.class, - // broken! - EdgeNGramTokenFilter.class + // TODO: fix basetokenstreamtestcase not to trip because this + one has no CharTermAtt + EmptyTokenizer.class, + // doesn't actual reset itself! + CachingTokenFilter.class, + // doesn't consume whole stream! + LimitTokenCountFilter.class, + // Not broken: we forcefully add this, so we shouldn't + // also randomly pick it: + ValidatingTokenFilter.class, + // NOTE: these by themselves won't cause any 'basic assertions' to fail. + // but see https://issues.apache.org/jira/browse/LUCENE-3920, + if any + // tokenfilter that combines words (e.g. shingles) comes after + them, + // this will create bogus offsets because their 'offsets go +
Re: svn commit: r1311920 - /lucene/dev/branches/lucene3969/modules/analysis/common/src/test/org/apache/lucene/analysis/core/TestRandomChains.java
On Tue, Apr 10, 2012 at 3:19 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: That's because emacs (and vim) indent blocks of code you haven't thought about yet, but will think about in 5 minutes from a given time... ;) The truth is far more mundane: somehow there's a bug in Emacs' handling of the imports ... which I've only ever hit on this one source file (what's wrong with it!), such that when I add an import (c-c +) it somehow went and removed ALL indentation and some other whitespace, for the first 200 lines or so so then I selected that and had it re-indent... Maybe time to upgrade Emacs! 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] (SOLR-3141) Deprecate OPTIMIZE command in Solr
[ https://issues.apache.org/jira/browse/SOLR-3141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13250984#comment-13250984 ] Erick Erickson commented on SOLR-3141: -- Does SolrJ then need to have a forceMerge rather than optimize? Which isn't deprecated in 3x BTW. Deprecate OPTIMIZE command in Solr -- Key: SOLR-3141 URL: https://issues.apache.org/jira/browse/SOLR-3141 Project: Solr Issue Type: Improvement Components: update Affects Versions: 3.5 Reporter: Jan Høydahl Labels: force, optimize Fix For: 4.0 Attachments: SOLR-3141.patch, SOLR-3141.patch Background: LUCENE-3454 renames optimize() as forceMerge(). Please read that issue first. Now that optimize() is rarely necessary anymore, and renamed in Lucene APIs, what should be done with Solr's ancient optimize command? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3970) Rename getUnique[Field/Terms]Count() into size()
[
https://issues.apache.org/jira/browse/LUCENE-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Iulius Curt updated LUCENE-3970:
Fix Version/s: 4.0
Rename getUnique[Field/Terms]Count() into size()
Key: LUCENE-3970
URL: https://issues.apache.org/jira/browse/LUCENE-3970
Project: Lucene - Java
Issue Type: Task
Components: core/index
Reporter: Iulius Curt
Priority: Minor
Fix For: 4.0
Attachments: LUCENE-3970.patch
Like Robert Muir said in LUCENE-3109:
{quote}Also I think there are other improvements we can do here that would be
more natural:
Fields.getUniqueFieldCount() - Fields.size()
Terms.getUniqueTermCount() - Terms.size(){quote}
I believe this dramatically improves understandability (way less 'scary',
actually beautiful).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-3970) Rename getUnique[Field/Terms]Count() into size()
[
https://issues.apache.org/jira/browse/LUCENE-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless reassigned LUCENE-3970:
--
Assignee: Michael McCandless
Rename getUnique[Field/Terms]Count() into size()
Key: LUCENE-3970
URL: https://issues.apache.org/jira/browse/LUCENE-3970
Project: Lucene - Java
Issue Type: Task
Components: core/index
Reporter: Iulius Curt
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.0
Attachments: LUCENE-3970.patch
Like Robert Muir said in LUCENE-3109:
{quote}Also I think there are other improvements we can do here that would be
more natural:
Fields.getUniqueFieldCount() - Fields.size()
Terms.getUniqueTermCount() - Terms.size(){quote}
I believe this dramatically improves understandability (way less 'scary',
actually beautiful).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe updated SOLR-3344:
--
Attachment: SOLR-3344-runtime-scope.patch
Patch switching Solr test-framework's Jetty dependencies' scope from compile to
runtime. All Solr tests pass. Committing shortly.
POM dependencies not all there yet for solr-test-framework
--
Key: SOLR-3344
URL: https://issues.apache.org/jira/browse/SOLR-3344
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Benson Margulies
Assignee: Steven Rowe
Fix For: 4.0
Attachments: 0001-Add-jetty-deps.patch,
SOLR-3344-runtime-scope.patch, SOLR-3344.patch
The pom for solr-test-framework does not mention jetty, so a test case that
doesn't get jetty into it's classpath otherwise fails with:
{noformat}
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3344) POM dependencies not all there yet for solr-test-framework
[
https://issues.apache.org/jira/browse/SOLR-3344?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe resolved SOLR-3344.
---
Resolution: Fixed
Committed compile-runtime scope changes in r1311957.
POM dependencies not all there yet for solr-test-framework
--
Key: SOLR-3344
URL: https://issues.apache.org/jira/browse/SOLR-3344
Project: Solr
Issue Type: Bug
Components: Build
Affects Versions: 4.0
Reporter: Benson Margulies
Assignee: Steven Rowe
Fix For: 4.0
Attachments: 0001-Add-jetty-deps.patch,
SOLR-3344-runtime-scope.patch, SOLR-3344.patch
The pom for solr-test-framework does not mention jetty, so a test case that
doesn't get jetty into it's classpath otherwise fails with:
{noformat}
java.lang.NoClassDefFoundError: org/eclipse/jetty/server/SessionIdManager
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3970) Rename getUnique[Field/Terms]Count() into size()
[
https://issues.apache.org/jira/browse/LUCENE-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13251004#comment-13251004
]
Michael McCandless commented on LUCENE-3970:
Thanks Iulius, this looks good ... I'll commit shortly.
Rename getUnique[Field/Terms]Count() into size()
Key: LUCENE-3970
URL: https://issues.apache.org/jira/browse/LUCENE-3970
Project: Lucene - Java
Issue Type: Task
Components: core/index
Reporter: Iulius Curt
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.0
Attachments: LUCENE-3970.patch
Like Robert Muir said in LUCENE-3109:
{quote}Also I think there are other improvements we can do here that would be
more natural:
Fields.getUniqueFieldCount() - Fields.size()
Terms.getUniqueTermCount() - Terms.size(){quote}
I believe this dramatically improves understandability (way less 'scary',
actually beautiful).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2690) Date Faceting or Range Faceting doesn't take timezone into account.
[ https://issues.apache.org/jira/browse/SOLR-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-2690: --- Attachment: SOLR-2690.patch David: I like the theory of your patch, but the implementation choices you made seem a little heavy handed. In particular I don't understand the need for your ExecuteWithThreadDateMathParser -- as i mentioned, the DateMathParser class already uses SolrRequestInfo to define the default NOW, we can use similar logic to define a default TZ w/o introducing as much complexity. I whipped up a quick patch that takes this approach -- please take a look and lemme know what you think. I did some quick manual testing and everything seems to be working, but obviously we need some good unit tests before we can commit (not sure when i'll have a chance to work on this so feel free to jump in if you want) bq. The timezone specified by 'tz' simply affects math done with dates Right -- this is really the only sane way for this to work -- if the client specifies an absolute time for start/end when faceting, we *have* to use that absolute time, we can't assume they mean for that to be rounded in some way relative the client's timezone -- rounded to what precision? Day? Month? Year?). Another digression... bq. One way to get what you want, which is the way people have been saying to do it, is to adjust the start and end manually. ... The issue with this approach is your manual adjusting gets tricking when talking about timezones that have day light savings time. You should never manually adjust times before sending them to solr -- If you have an absolute abstract moment in time, then you should format that abstract moment of time as string using then canonical solr date format (which requires the use of UTC in the format). If you are starting with a string representation of some absolute abstract moment of time that has been formated using some other arbitrary format and/or timezone, you should _parse_ it into an abstract moment in time (using a date parsing library that knows about the rules of your timezone -- any decent one should know about all the timezone data), and *then* format that abstract moment of time as string using the canonical solr date format. Date Faceting or Range Faceting doesn't take timezone into account. --- Key: SOLR-2690 URL: https://issues.apache.org/jira/browse/SOLR-2690 Project: Solr Issue Type: Improvement Affects Versions: 3.3 Reporter: David Schlotfeldt Attachments: SOLR-2690.patch, add-tz-parameter.patch, add-tz-parameter.patch, timezone-facet-component.tgz Original Estimate: 3h Remaining Estimate: 3h Timezone needs to be taken into account when doing date math. Currently it isn't. DateMathParser instances created are always being constructed with UTC. This is a huge issue when it comes to faceting. Depending on your timezone day-light-savings changes the length of a month. A facet gap of +1MONTH is different depending on the timezone and the time of the year. I believe the issue is very simple to fix. There are three places in the code DateMathParser is created. All three are configured with the timezone being UTC. If a user could specify the TimeZone to pass into DateMathParser this faceting issue would be resolved. Though it would be nice if we could always specify the timezone DateMathParser uses (since date math DOES depend on timezone) its really only essential that we can affect DateMathParser the SimpleFacets uses when dealing with the gap of the date facets. Another solution is to expand the syntax of the expressions DateMathParser understands. For example we could allow (?timeZone=VALUE) to be added anywhere within an expression. VALUE would be the id of the timezone. When DateMathParser reads this in sets the timezone on the Calendar it is using. Two examples: - (?timeZone=America/Chicago)NOW/YEAR - (?timeZone=America/Chicago)+1MONTH I would be more then happy to modify DateMathParser and provide a patch. I just need a committer to agree this needs to be resolved and a decision needs to be made on the syntax used Thanks! David -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2690) Date Math should allow clients to override timezone used for rounding (faceting queries)
[ https://issues.apache.org/jira/browse/SOLR-2690?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-2690: --- Description: Timezone needs to be taken into account when doing date math. Currently it isn't. DateMathParser instances created are always being constructed with UTC. This is a huge issue when it comes to faceting. Depending on your timezone day-light-savings changes the length of a month. A facet gap of +1MONTH is different depending on the timezone and the time of the year. I believe the issue is very simple to fix. There are three places in the code DateMathParser is created. All three are configured with the timezone being UTC. If a user could specify the TimeZone to pass into DateMathParser this faceting issue would be resolved. was: Timezone needs to be taken into account when doing date math. Currently it isn't. DateMathParser instances created are always being constructed with UTC. This is a huge issue when it comes to faceting. Depending on your timezone day-light-savings changes the length of a month. A facet gap of +1MONTH is different depending on the timezone and the time of the year. I believe the issue is very simple to fix. There are three places in the code DateMathParser is created. All three are configured with the timezone being UTC. If a user could specify the TimeZone to pass into DateMathParser this faceting issue would be resolved. Though it would be nice if we could always specify the timezone DateMathParser uses (since date math DOES depend on timezone) its really only essential that we can affect DateMathParser the SimpleFacets uses when dealing with the gap of the date facets. Another solution is to expand the syntax of the expressions DateMathParser understands. For example we could allow (?timeZone=VALUE) to be added anywhere within an expression. VALUE would be the id of the timezone. When DateMathParser reads this in sets the timezone on the Calendar it is using. Two examples: - (?timeZone=America/Chicago)NOW/YEAR - (?timeZone=America/Chicago)+1MONTH I would be more then happy to modify DateMathParser and provide a patch. I just need a committer to agree this needs to be resolved and a decision needs to be made on the syntax used Thanks! David Affects Version/s: (was: 3.3) Assignee: Hoss Man Summary: Date Math should allow clients to override timezone used for rounding (faceting queries) (was: Date Faceting or Range Faceting doesn't take timezone into account.) editing summary description to clarify this isn't just about faceting, but date math in general. Date Math should allow clients to override timezone used for rounding (faceting queries) -- Key: SOLR-2690 URL: https://issues.apache.org/jira/browse/SOLR-2690 Project: Solr Issue Type: Improvement Reporter: David Schlotfeldt Assignee: Hoss Man Attachments: SOLR-2690.patch, add-tz-parameter.patch, add-tz-parameter.patch, timezone-facet-component.tgz Original Estimate: 3h Remaining Estimate: 3h Timezone needs to be taken into account when doing date math. Currently it isn't. DateMathParser instances created are always being constructed with UTC. This is a huge issue when it comes to faceting. Depending on your timezone day-light-savings changes the length of a month. A facet gap of +1MONTH is different depending on the timezone and the time of the year. I believe the issue is very simple to fix. There are three places in the code DateMathParser is created. All three are configured with the timezone being UTC. If a user could specify the TimeZone to pass into DateMathParser this faceting issue would be resolved. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: How to make tarballs
Have you tried ant dist?
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com
On 9. apr. 2012, at 22:22, Benson Margulies wrote:
While waiting for the NB's to get better, I'd like to make my own Solr
tarball of my own build. I'm not getting very far with the script in
dev-tools:
python -u dev-tools/scripts/buildAndPushRelease.py . 4.0-SNAPSHOT 0
Traceback (most recent call last):
File dev-tools/scripts/buildAndPushRelease.py, line 293, in module
main()
File dev-tools/scripts/buildAndPushRelease.py, line 275, in main
rev = open('rev.txt').read()
IOError: [Errno 2] No such file or directory: 'rev.txt'
Can someone please give me a hint?
-
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-3970) Rename getUnique[Field/Terms]Count() into size()
[
https://issues.apache.org/jira/browse/LUCENE-3970?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless resolved LUCENE-3970.
Resolution: Fixed
Thanks Iulius!
Rename getUnique[Field/Terms]Count() into size()
Key: LUCENE-3970
URL: https://issues.apache.org/jira/browse/LUCENE-3970
Project: Lucene - Java
Issue Type: Task
Components: core/index
Reporter: Iulius Curt
Assignee: Michael McCandless
Priority: Minor
Fix For: 4.0
Attachments: LUCENE-3970.patch
Like Robert Muir said in LUCENE-3109:
{quote}Also I think there are other improvements we can do here that would be
more natural:
Fields.getUniqueFieldCount() - Fields.size()
Terms.getUniqueTermCount() - Terms.size(){quote}
I believe this dramatically improves understandability (way less 'scary',
actually beautiful).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: How to make tarballs
On Tue, Apr 10, 2012 at 7:17 PM, Jan Høydahl jan@cominvent.com wrote:
Have you tried ant dist?
I eventually figured out that the problem was that you need to cd to
'solr' before running ant dist. I had tried it at top level
originally.
--
Jan Høydahl, search solution architect
Cominvent AS - www.cominvent.com
Solr Training - www.solrtraining.com
On 9. apr. 2012, at 22:22, Benson Margulies wrote:
While waiting for the NB's to get better, I'd like to make my own Solr
tarball of my own build. I'm not getting very far with the script in
dev-tools:
python -u dev-tools/scripts/buildAndPushRelease.py . 4.0-SNAPSHOT 0
Traceback (most recent call last):
File dev-tools/scripts/buildAndPushRelease.py, line 293, in module
main()
File dev-tools/scripts/buildAndPushRelease.py, line 275, in main
rev = open('rev.txt').read()
IOError: [Errno 2] No such file or directory: 'rev.txt'
Can someone please give me a hint?
-
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] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated SOLR-3347: --- Attachment: provision-and-start.sh solrconfig.xml deleteByQuery failing with SolrCloud Key: SOLR-3347 URL: https://issues.apache.org/jira/browse/SOLR-3347 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Benson Margulies Attachments: 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch, provision-and-start.sh, solrconfig.xml I've got a SolrCloud configuration in which calling deleteByQuery on CloudSolrServer never works. The log looks plausible, but the documents never leave. In the debugger, the dbqlevel in DistributedUpdateProcessor never gets to 3. I'm going to attach a number of things. One is a unit test that passes, sadly. Someone might like some small improvements in there in the cloud test classes, even if you don't bother with the test itself. Another is the solrconfig.xml that fails, and a third is the shell script I use to launch. I'm continuing to work on this; I guess the next step is to allow you to repro what I'm doing by replacing my private URP with a dummy and seeing if I can get the same wrong results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3347) deleteByQuery failing with SolrCloud
deleteByQuery failing with SolrCloud Key: SOLR-3347 URL: https://issues.apache.org/jira/browse/SOLR-3347 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Benson Margulies Attachments: 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch, provision-and-start.sh, solrconfig.xml I've got a SolrCloud configuration in which calling deleteByQuery on CloudSolrServer never works. The log looks plausible, but the documents never leave. In the debugger, the dbqlevel in DistributedUpdateProcessor never gets to 3. I'm going to attach a number of things. One is a unit test that passes, sadly. Someone might like some small improvements in there in the cloud test classes, even if you don't bother with the test itself. Another is the solrconfig.xml that fails, and a third is the shell script I use to launch. I'm continuing to work on this; I guess the next step is to allow you to repro what I'm doing by replacing my private URP with a dummy and seeing if I can get the same wrong results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3347) deleteByQuery failing with SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-3347?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Benson Margulies updated SOLR-3347: --- Attachment: 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch A patch as explained. deleteByQuery failing with SolrCloud Key: SOLR-3347 URL: https://issues.apache.org/jira/browse/SOLR-3347 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Benson Margulies Attachments: 0001-Attempt-to-repro-problem-with-del-and-SolrCloud.patch, provision-and-start.sh, solrconfig.xml I've got a SolrCloud configuration in which calling deleteByQuery on CloudSolrServer never works. The log looks plausible, but the documents never leave. In the debugger, the dbqlevel in DistributedUpdateProcessor never gets to 3. I'm going to attach a number of things. One is a unit test that passes, sadly. Someone might like some small improvements in there in the cloud test classes, even if you don't bother with the test itself. Another is the solrconfig.xml that fails, and a third is the shell script I use to launch. I'm continuing to work on this; I guess the next step is to allow you to repro what I'm doing by replacing my private URP with a dummy and seeing if I can get the same wrong results. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2605) CoreAdminHandler, different Output while 'defaultCoreName' is specified
[
https://issues.apache.org/jira/browse/SOLR-2605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-2605:
---
Attachment: SOLR-2605.patch
steffkes: your patch applies cleanly, but didn't compile -- it looks like you
modified some files that weren't included in the patch?
based on the hoops it looked like you were having to jump through to track
this, i looked at where/how/why were were throwing away the core name if it was
the default core, and took a crack at just undo-ing that mess so that every
core knows it's real and true name -- and only the CoreContainer worries about
what the name of the default core is -- this only required two tweaks to tests
(and one of those was to eliminate special hoops TestJmxIntegration was jumping
through to get the right name if the core was the default!)
Once that was done, CoreAdminHandler seemed to return consistent name info in
the status for every core, regardless of how many there were, or if a default
name was in use. So then since i figured it would be handy, i added the
defaultCoreName to the output when you get status for all cores (either a
string or null if there is no default core name) and for good measure i also
put an isDefault boolean in the status for each core.
try this out and see if does everything you need/want to make the UI go vroom
... like i said, all tests pass for me, but i don't want to commit w/o some
review from miller -- this fix seems so easy i don't understand why the logic
was reversed before, so i'm scared i may be missing something
CoreAdminHandler, different Output while 'defaultCoreName' is specified
---
Key: SOLR-2605
URL: https://issues.apache.org/jira/browse/SOLR-2605
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 4.0
Attachments: SOLR-2399-admin-cores-default.xml,
SOLR-2399-admin-cores.xml, SOLR-2605.patch, SOLR-2605.patch
The attached XML-Files show the little difference between a defined
{{defaultCoreName}}-Attribute and a non existing one.
Actually the new admin ui checks for an core with empty name to set single- /
multicore-settings .. it's a quick change to count the number of defined
cores instead.
But, will it be possible, to get the core-name (again)? One of both
attributes would be enough, if that makes a difference :)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-381) delete-by-query does not support purely negative queries
[
https://issues.apache.org/jira/browse/SOLR-381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man updated SOLR-381:
--
Description:
Reported by Rob Casson:
{noformat}
indexing the example docs from 1.2, these steps work:
curl http://localhost:8983/solr/update --data-binary
'deletequerysolr/query/delete' -H 'Content-type:text/xml;
charset=utf-8'
curl http://localhost:8983/solr/update --data-binary 'optimize /' -H
'Content-type:text/xml; charset=utf-8'
but if i reindex, and change the delete query to a negative, the
non-'solr' docs don't get deleted:
curl http://localhost:8983/solr/update --data-binary
'deletequery-solr/query/delete' -H 'Content-type:text/xml;
charset=utf-8'
curl http://localhost:8983/solr/update --data-binary 'optimize /' -H
'Content-type:text/xml; charset=utf-8'
And detailed by Hoss with a workaround:
the delete by query does the
right thing with a purely negative query ... when the customization was
added to Solr to support pure negative queries it was done at the
SolrIndexSearcher level when computing DocSets, but delete by query uses a
lower level method passing in a HitCOllector.
the work arround is to include *:* in yoru query ...
deletequery*:* -solr/query/delete
... if/when this is fixed
in Solr that's esentally what solr will do under the covers.
{noformat}
was:
Reported by Rob Casson:
indexing the example docs from 1.2, these steps work:
curl http://localhost:8983/solr/update --data-binary
'deletequerysolr/query/delete' -H 'Content-type:text/xml;
charset=utf-8'
curl http://localhost:8983/solr/update --data-binary 'optimize /' -H
'Content-type:text/xml; charset=utf-8'
but if i reindex, and change the delete query to a negative, the
non-'solr' docs don't get deleted:
curl http://localhost:8983/solr/update --data-binary
'deletequery-solr/query/delete' -H 'Content-type:text/xml;
charset=utf-8'
curl http://localhost:8983/solr/update --data-binary 'optimize /' -H
'Content-type:text/xml; charset=utf-8'
And detailed by Hoss with a workaround:
the delete by query does the
right thing with a purely negative query ... when the customization was
added to Solr to support pure negative queries it was done at the
SolrIndexSearcher level when computing DocSets, but delete by query uses a
lower level method passing in a HitCOllector.
the work arround is to include *:* in yoru query ...
deletequery*:* -solr/query/delete
... if/when this is fixed
in Solr that's esentally what solr will do under the covers.
updating summary to use jira's noformat tag so that it doesn't interpret the
query syntax as wiki markup
Daivd: this issue was open before wiki markup was supported in issue summaries,
so jira was showing you {{ : }} when it should have been showing you {{ \*:\* }}
delete-by-query does not support purely negative queries
Key: SOLR-381
URL: https://issues.apache.org/jira/browse/SOLR-381
Project: Solr
Issue Type: Bug
Components: update
Reporter: Erik Hatcher
Priority: Minor
Reported by Rob Casson:
{noformat}
indexing the example docs from 1.2, these steps work:
curl http://localhost:8983/solr/update --data-binary
'deletequerysolr/query/delete' -H 'Content-type:text/xml;
charset=utf-8'
curl http://localhost:8983/solr/update --data-binary 'optimize /' -H
'Content-type:text/xml; charset=utf-8'
but if i reindex, and change the delete query to a negative, the
non-'solr' docs don't get deleted:
curl http://localhost:8983/solr/update --data-binary
'deletequery-solr/query/delete' -H 'Content-type:text/xml;
charset=utf-8'
curl http://localhost:8983/solr/update --data-binary 'optimize /' -H
'Content-type:text/xml; charset=utf-8'
And detailed by Hoss with a workaround:
the delete by query does the
right thing with a purely negative query ... when the customization was
added to Solr to support pure negative queries it was done at the
SolrIndexSearcher level when computing DocSets, but delete by query uses a
lower level method passing in a HitCOllector.
the work arround is to include *:* in yoru query ...
deletequery*:* -solr/query/delete
... if/when this is fixed
in Solr that's esentally what solr will do under the covers.
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3348) Garbled with shards search
Garbled with shards search
--
Key: SOLR-3348
URL: https://issues.apache.org/jira/browse/SOLR-3348
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 4.0
Environment: windows 7
Reporter: 震宇 蒋
When searching for Chinese characters, such as 浙江,eclipse logs like:
...
四月 11, 2012 12:18:24 上午 org.apache.solr.core.SolrCore execute
信息: [badperson1] webapp=/FTSearch2 path=/select
params={shards.qt=sharddistrib=falsewt=javabinrows=40version=2fl=_UUID,scoreshard.url=127.0.0.1:8080/FTSearch2/badperson1NOW=1334074224397start=0q=??isShard=trueqt=shardfsv=true}
hits=1012456 status=0 QTime=63409
四月 11, 2012 12:20:54 上午 org.apache.solr.core.SolrCore execute
信息: [badperson1] webapp=/FTSearch2 path=/select
params={NOW=1334074224397shard.url=127.0.0.1:8080/FTSearch2/badperson1start=30shards.qt=shardids=1692455e-fcfc-451a-9221-80d0e483ab9e,e529d2fa-442d-48a7-9dea-86a6c1abf510,685d90dc-bf92-47df-9fa7-634a9c5a7330,6c17abd4-21a4-46c2-8cfb-3ad33e966c9b,fa5b4fe6-f1b5-4cf3-941a-6b2f4bc98df2,fe3e483f-68a2-4dd7-87c2-f0811d515249,ce84a4b0-777d-4663-a26d-7a9a1800e1af,2f224a5a-754b-4cea-a72e-ea52c224e846,31c27427-e0ba-4327-8eb4-4f968fce7a51,48cd8be9-c7ca-4a3c-b3b4-662d47fed5feq=??distrib=falsewt=javabinqt=shardisShard=trueversion=2rows=10}
status=0 QTime=26754 四月 11, 2012 12:21:05 上午 org.apache.solr.core.SolrCore
execute
信息: [] webapp=/FTSearch2 path=/select params={start=30q=浙江rows=10} status=0
QTime=641335
...
*My Solution：*
??org.apache.solr.client.solrj.impl.HttpSolrServer row:269??
for (String value : vals) {
entity.addPart(name, new
StringBody(value,{color:red}Charset.forName(UTF-8){color}));
}
??org.apache.solr.servlet.SolrRequestParsers row:335??
ServletFileUpload upload = new ServletFileUpload(factory);
upload.setSizeMax(uploadLimitKB * 1024);
{color:red}upload.setHeaderEncoding(UTF-8);{color}
List items = upload.parseRequest(req);
Iterator iter = items.iterator();
while (iter.hasNext()) {
FileItem item = (FileItem) iter.next();
if (item.isFormField()) {
MultiMapSolrParams.addParam(item.getFieldName(),
item.getString({color:red}UTF-8{color}),
params.getMap());
}
...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] branch-3x Build # 1334114821 - Failure
Build failure running tests You can see the entire build log at http://sierranevada.servebeer.com/1334114821.log Summary of tests that failed... ./solr/build/solr-solrj/test/TEST-org.apache.solr.common.util.ContentStreamTest.xml Thanks, Charlie Cron (version 2.0-hossman-patched) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3343) Move non-shared utils from solrj to solr core
[
https://issues.apache.org/jira/browse/SOLR-3343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Chris Male updated SOLR-3343:
-
Attachment: SOLR-3343.patch
Patch for moving the utils I felt should be moved. Since I used svn 1.6 still,
the patch must be executed after the following command:
{noformat}
svn mv solr/solrj/src/java/org/apache/solr/common/util/DOMUtil.java
solr/core/src/java/org/apache/solr/util/DOMUtil.java
svn mv solr/solrj/src/java/org/apache/solr/common/util/FastWriter.java
solr/core/src/java/org/apache/solr/util/FastWriter.java
svn mv solr/solrj/src/java/org/apache/solr/common/util/FileUtils.java
solr/core/src/java/org/apache/solr/util/FileUtils.java
svn mv solr/solrj/src/java/org/apache/solr/common/util/RegexFileFilter.java
solr/core/src/java/org/apache/solr/util/RegexFileFilter.java
svn mv solr/solrj/src/java/org/apache/solr/common/util/RTimer.java
solr/core/src/java/org/apache/solr/util/RTimer.java
svn mv solr/solrj/src/java/org/apache/solr/common/util/SystemIdResolver.java
solr/core/src/java/org/apache/solr/util/SystemIdResolver.java
svn mv
solr/solrj/src/test/org/apache/solr/common/util/TestSystemIdResolver.java
solr/core/src/test/org/apache/solr/util/TestSystemIdResolver.java
svn mv solr/solrj/src/test/org/apache/solr/common/util/FileUtilsTest.java
solr/core/src/test/org/apache/solr/util/FileUtilsTest.java
svn mv solr/solrj/src/test/org/apache/solr/common/util/DOMUtilTest.java
solr/core/src/test/org/apache/solr/util/DOMUtilTest.java
{noformat}
I will commit this soon as I want to get onto some other refactoring.
Move non-shared utils from solrj to solr core
-
Key: SOLR-3343
URL: https://issues.apache.org/jira/browse/SOLR-3343
Project: Solr
Issue Type: Improvement
Reporter: Chris Male
Attachments: SOLR-3343.patch
When doing some unrelated refactoring, I found myself making changes to a
class in solrj's {{org.apache.solr.common}} which surprised me. Under closer
examination the class was only used inside Solr core and DIH.
I think {{common}} in solrj should only contain those classes which are
shared between solrj and other modules. Anything thats not used by solrj
should go into solr core (or whatever other module actually makes use of it).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
