date:20121005

See http://sierranevada.servebeer.com/job/lucene40-beaster/1594/

--
[...truncated 874 lines...]
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestRegexpRandom
[junit4:junit4] Completed on J1 in 0.13s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestTermRangeQuery
[junit4:junit4] Completed on J0 in 0.25s, 7 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.search.TestSimpleExplanationsOfNonMatches
[junit4:junit4] Completed on J3 in 0.16s, 69 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper
[junit4:junit4] Completed on J1 in 0.15s, 4 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestAutomatonQuery
[junit4:junit4] Completed on J0 in 0.18s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestWildcardRandom
[junit4:junit4] Completed on J3 in 0.10s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestBooleanOr
[junit4:junit4] Completed on J2 in 0.35s, 6 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.search.TestComplexExplanationsOfNonMatches
[junit4:junit4] Completed on J1 in 0.05s, 22 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestRegexpQuery
[junit4:junit4] Completed on J0 in 0.11s, 7 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestDocCount
[junit4:junit4] Completed on J2 in 0.09s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
[junit4:junit4] Completed on J1 in 0.04s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestUniqueTermCount
[junit4:junit4] Completed on J0 in 0.08s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.spans.TestNearSpansOrdered
[junit4:junit4] Completed on J3 in 0.36s, 10 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.TestSearchForDuplicates
[junit4:junit4] Completed on J2 in 0.04s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestSmallFloat
[junit4:junit4] Completed on J1 in 0.04s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms
[junit4:junit4] Completed on J0 in 0.03s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex
[junit4:junit4] Completed on J3 in 0.03s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestIndexFileDeleter
[junit4:junit4] Completed on J2 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestTopDocsCollector
[junit4:junit4] Completed on J1 in 0.15s, 8 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestBeforeAfterOverrides
[junit4:junit4] Completed on J0 in 0.03s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestFilteredSearch
[junit4:junit4] Completed on J3 in 0.03s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestCachingWrapperFilter
[junit4:junit4] Completed on J2 in 0.06s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestTermScorer
[junit4:junit4] Completed on J1 in 0.02s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.util.junitcompat.TestSameRandomnessLocalePassedOrNot
[junit4:junit4] Completed on J0 in 0.03s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.index.TestFilterAtomicReader
[junit4:junit4] Completed on J3 in 0.07s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestMultiTermQueryRewrites
[junit4:junit4] Completed on J2 in 0.02s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSeedFromUncaught
[junit4:junit4] Completed on J1 in 0.03s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced
[junit4:junit4] Completed on J0 in 0.09s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.search.TestConstantScoreQuery
[junit4:junit4] Completed on J3 in 0.08s, 3 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.document.TestDateTools
[junit4:junit4] Completed on J2 in 0.02s, 5 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.store.TestDirectory
[junit4:junit4] IGNOR/A 0.00s J1 | TestDirectory.testThreadSafety
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] Completed on J1 in 0.02s, 8 tests, 1 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestJUnitRuleOrder
[junit4:junit4] Completed on J0 in 0.02s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.TestCharsRef
[junit4:junit4] Completed on J3 in 0.02s, 8 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestCodecReported
[junit4:junit4] Completed on J2 in 0.01s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite:

Jenkins build is back to normal : lucene40-beaster #1595

See http://sierranevada.servebeer.com/job/lucene40-beaster/1595/


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (LUCENE-4426) New ValueSource implementations that wrap DocValues


 [ 
https://issues.apache.org/jira/browse/LUCENE-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adrien Grand updated LUCENE-4426:
-

Attachment: LUCENE-4426.patch

New patch :
 - added optimisation when SortedSource.hasPackedDocToOrd() is true,
 - a few more tests.

 New ValueSource implementations that wrap DocValues
 ---

 Key: LUCENE-4426
 URL: https://issues.apache.org/jira/browse/LUCENE-4426
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/other
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.1, 5.0

 Attachments: LUCENE-4426.patch, LUCENE-4426.patch, LUCENE-4426.patch


 We should have ValueSource implementations that wrap DocValues in 
 lucene-queries so that DocValues can be used in function queries.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: Build failed in Jenkins: lucene40-beaster #1594

Same failure (TestIndexWriterReader.testDuringAddIndexes).

Mike McCandless

http://blog.mikemccandless.com

On Fri, Oct 5, 2012 at 5:26 AM,  hudsonsevilt...@gmail.com wrote:
 See http://sierranevada.servebeer.com/job/lucene40-beaster/1594/

 --
 [...truncated 874 lines...]
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestRegexpRandom
 [junit4:junit4] Completed on J1 in 0.13s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestTermRangeQuery
 [junit4:junit4] Completed on J0 in 0.25s, 7 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.TestSimpleExplanationsOfNonMatches
 [junit4:junit4] Completed on J3 in 0.16s, 69 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper
 [junit4:junit4] Completed on J1 in 0.15s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestAutomatonQuery
 [junit4:junit4] Completed on J0 in 0.18s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestWildcardRandom
 [junit4:junit4] Completed on J3 in 0.10s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestBooleanOr
 [junit4:junit4] Completed on J2 in 0.35s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.TestComplexExplanationsOfNonMatches
 [junit4:junit4] Completed on J1 in 0.05s, 22 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestRegexpQuery
 [junit4:junit4] Completed on J0 in 0.11s, 7 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestDocCount
 [junit4:junit4] Completed on J2 in 0.09s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
 [junit4:junit4] Completed on J1 in 0.04s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestUniqueTermCount
 [junit4:junit4] Completed on J0 in 0.08s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.spans.TestNearSpansOrdered
 [junit4:junit4] Completed on J3 in 0.36s, 10 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.TestSearchForDuplicates
 [junit4:junit4] Completed on J2 in 0.04s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestSmallFloat
 [junit4:junit4] Completed on J1 in 0.04s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms
 [junit4:junit4] Completed on J0 in 0.03s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex
 [junit4:junit4] Completed on J3 in 0.03s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestIndexFileDeleter
 [junit4:junit4] Completed on J2 in 0.02s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestTopDocsCollector
 [junit4:junit4] Completed on J1 in 0.15s, 8 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestBeforeAfterOverrides
 [junit4:junit4] Completed on J0 in 0.03s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestFilteredSearch
 [junit4:junit4] Completed on J3 in 0.03s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestCachingWrapperFilter
 [junit4:junit4] Completed on J2 in 0.06s, 5 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestTermScorer
 [junit4:junit4] Completed on J1 in 0.02s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestSameRandomnessLocalePassedOrNot
 [junit4:junit4] Completed on J0 in 0.03s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestFilterAtomicReader
 [junit4:junit4] Completed on J3 in 0.07s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestMultiTermQueryRewrites
 [junit4:junit4] Completed on J2 in 0.02s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSeedFromUncaught
 [junit4:junit4] Completed on J1 in 0.03s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced
 [junit4:junit4] Completed on J0 in 0.09s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestConstantScoreQuery
 [junit4:junit4] Completed on J3 in 0.08s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.document.TestDateTools
 [junit4:junit4] Completed on J2 in 0.02s, 5 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.store.TestDirectory
 [junit4:junit4] IGNOR/A 0.00s J1 | TestDirectory.testThreadSafety
 [junit4:junit4] Assumption #1: 'nightly' test group is disabled 
 (@Nightly)
 [junit4:junit4] Completed on J1 in 0.02s, 8 tests, 1 skipped
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestJUnitRuleOrder
 [junit4:junit4] Completed on J0 in 0.02s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite:

Re: [JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 54 - Failure

TestBagOfPostings timed out: it got maxBuffereDocs 2 and the
AlcoholicMergePolicy!!  A bad combination ... I'll change it to
increase maxBufferedDocs ...

Mike McCandless

http://blog.mikemccandless.com

On Fri, Oct 5, 2012 at 4:21 AM, Apache Jenkins Server
jenk...@builds.apache.org wrote:
 Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/54/

 6 tests failed.
 REGRESSION:  org.apache.lucene.index.TestBagOfPostings.test

 Error Message:
 Test abandoned because suite timeout was reached.

 Stack Trace:
 java.lang.Exception: Test abandoned because suite timeout was reached.
 at __randomizedtesting.SeedInfo.seed([88207056F447E506]:0)


 FAILED:  junit.framework.TestSuite.org.apache.lucene.index.TestBagOfPostings

 Error Message:
 Suite timeout exceeded (= 720 msec).

 Stack Trace:
 java.lang.Exception: Suite timeout exceeded (= 720 msec).
 at __randomizedtesting.SeedInfo.seed([88207056F447E506]:0)


 REGRESSION:  
 org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule.testRuleInvariantBeforeClass

 Error Message:
 expected:1 but was:0

 Stack Trace:
 java.lang.AssertionError: expected:1 but was:0
 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.util.junitcompat.TestSystemPropertiesInvariantRule.testRuleInvariantBeforeClass(TestSystemPropertiesInvariantRule.java:114)
 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 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
 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.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
 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.runners.ParentRunner.run(ParentRunner.java:300)
 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:161)
 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:255)
 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)


 REGRESSION:  
 org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule.testRuleInvariantAfterClass

 Error Message:
 expected:1 but was:0

 Stack Trace:
 java.lang.AssertionError: expected:1 but was:0
 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.util.junitcompat.TestSystemPropertiesInvariantRule.testRuleInvariantAfterClass(TestSystemPropertiesInvariantRule.java:123)
 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

[jira] [Created] (SOLR-3914) Solr 3.6.1 Tutorial links to http://localhost:8983

2012-10-05 Thread Marcel Becker (JIRA)

Marcel Becker created SOLR-3914:
---

 Summary: Solr 3.6.1 Tutorial links to http://localhost:8983
 Key: SOLR-3914
 URL: https://issues.apache.org/jira/browse/SOLR-3914
 Project: Solr
  Issue Type: Bug
  Components: documentation
Affects Versions: 3.6.1
Reporter: Marcel Becker
Priority: Minor


In your documentation (tutorial) at

http://lucene.apache.org/solr/api-3_6_1/doc-files/tutorial.html

several links point at 

http://localhost:8983/solr/

I'm totally new to your project, thus, I cannot guess what the correct URL 
would be.

Thanks a lot for the documentation :)



--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: Build failed in Jenkins: slow-io-beasting #1049

Already committed a fix ...

Mike McCandless

http://blog.mikemccandless.com


On Fri, Oct 5, 2012 at 1:13 AM,  hudsonsevilt...@gmail.com wrote:
 See http://sierranevada.servebeer.com:8080/job/slow-io-beasting/1049/

 --
 [...truncated 902 lines...]
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestIndexableField
 [junit4:junit4] Completed on J1 in 0.14s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestDocTermOrds
 [junit4:junit4] Completed on J2 in 0.23s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestMultiPhraseQuery
 [junit4:junit4] Completed on J3 in 0.25s, 16 tests, 1 skipped
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.similarities.TestSimilarity2
 [junit4:junit4] Completed on J1 in 0.20s, 7 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestTermVectorsReader
 [junit4:junit4] Completed on J0 in 0.28s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestMultiLevelSkipList
 [junit4:junit4] Completed on J3 in 0.13s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.automaton.TestBasicOperations
 [junit4:junit4] Completed on J1 in 0.14s, 8 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.TestExternalCodecs
 [junit4:junit4] Completed on J0 in 0.12s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestFuzzyQuery
 [junit4:junit4] Completed on J3 in 0.13s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestRollingBuffer
 [junit4:junit4] Completed on J1 in 0.06s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.codecs.lucene40.TestAllFilesHaveCodecHeader
 [junit4:junit4] Completed on J2 in 0.70s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced2
 [junit4:junit4] Completed on J0 in 0.08s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestSizeBoundedForceMerge
 [junit4:junit4] Completed on J3 in 0.06s, 11 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestIdentityHashSet
 [junit4:junit4] Completed on J1 in 0.11s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper
 [junit4:junit4] Completed on J2 in 0.05s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestDocCount
 [junit4:junit4] Completed on J3 in 0.16s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms
 [junit4:junit4] Completed on J1 in 0.03s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.document.TestDocument
 [junit4:junit4] Completed on J2 in 0.05s, 10 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestAutomatonQuery
 [junit4:junit4] Completed on J0 in 0.31s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestIndexFileDeleter
 [junit4:junit4] Completed on J3 in 0.03s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestSetOnce
 [junit4:junit4] Completed on J2 in 0.02s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining
 [junit4:junit4] Completed on J0 in 0.03s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestSameRandomnessLocalePassedOrNot
 [junit4:junit4] Completed on J3 in 0.03s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestTopDocsCollector
 [junit4:junit4] Completed on J1 in 0.27s, 8 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.Test2BPostings
 [junit4:junit4] IGNOR/A 0.02s J2 | Test2BPostings.test
 [junit4:junit4] Assumption #1: 'nightly' test group is disabled 
 (@Nightly)
 [junit4:junit4] Completed on J2 in 0.03s, 1 test, 1 skipped
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestFilterAtomicReader
 [junit4:junit4] Completed on J0 in 0.03s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestFieldValueFilter
 [junit4:junit4] Completed on J3 in 0.22s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.store.TestFileSwitchDirectory
 [junit4:junit4] Completed on J1 in 0.06s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestDateFilter
 [junit4:junit4] Completed on J2 in 0.08s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestMultiTermQueryRewrites
 [junit4:junit4] Completed on J0 in 0.03s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced
 [junit4:junit4] Completed on J3 in 0.09s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestPositionIncrement
 [junit4:junit4] Completed on J1 in 0.03s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.document.TestDateTools
 [junit4:junit4]

[jira] [Commented] (LUCENE-3167) Make lucene/solr a OSGI bundle through Ant


[ 
https://issues.apache.org/jira/browse/LUCENE-3167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470272#comment-13470272
 ] 

Robert Muir commented on LUCENE-3167:
-

{quote}
What Gunnar Wagenknecht says he's doing now seems close?:
{quote}

Right, which begs the question if people who understand this stuff can already
do this downstream, why should we (people who work on search engines) do it.

Its just more stuff to go wrong when trying to release.

 Make lucene/solr a OSGI bundle through Ant
 --

 Key: LUCENE-3167
 URL: https://issues.apache.org/jira/browse/LUCENE-3167
 Project: Lucene - Core
  Issue Type: New Feature
 Environment: bndtools
Reporter: Luca Stancapiano
 Attachments: LUCENE-3167.patch, LUCENE-3167.patch, LUCENE-3167.patch, 
 lucene_trunk.patch, lucene_trunk.patch


 We need to make a bundle thriugh Ant, so the binary can be published and no 
 more need the download of the sources. Actually to get a OSGI bundle we need 
 to use maven tools and build the sources. Here the reference for the creation 
 of the OSGI bundle through Maven:
 https://issues.apache.org/jira/browse/LUCENE-1344
 Bndtools could be used inside Ant

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3914) Solr 3.6.1 Tutorial links to http://localhost:8983

2012-10-05 Thread Jack Krupansky (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470276#comment-13470276
 ] 

Jack Krupansky commented on SOLR-3914:
--

That IS the correct URL for a Solr instance running locally. The idea is that 
you install Solr locally (running with its embedded Jetty container) and then 
read the tutorial, executing the example commands as you go. Those links should 
take you to Solr in your browser.


 Solr 3.6.1 Tutorial links to http://localhost:8983
 --

 Key: SOLR-3914
 URL: https://issues.apache.org/jira/browse/SOLR-3914
 Project: Solr
  Issue Type: Bug
  Components: documentation
Affects Versions: 3.6.1
Reporter: Marcel Becker
Priority: Minor

 In your documentation (tutorial) at
 http://lucene.apache.org/solr/api-3_6_1/doc-files/tutorial.html
 several links point at 
 http://localhost:8983/solr/
 I'm totally new to your project, thus, I cannot guess what the correct URL 
 would be.
 Thanks a lot for the documentation :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-1604) Wildcards, ORs etc inside Phrase Queries

2012-10-05 Thread Ahmet Arslan (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-1604?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Ahmet Arslan updated SOLR-1604:
---

Attachment: ComplexPhrase.zip

this supposed to work with solr 4.0

 Wildcards, ORs etc inside Phrase Queries
 

 Key: SOLR-1604
 URL: https://issues.apache.org/jira/browse/SOLR-1604
 Project: Solr
  Issue Type: Improvement
  Components: search
Affects Versions: 1.4
Reporter: Ahmet Arslan
Priority: Minor
 Attachments: ASF.LICENSE.NOT.GRANTED--ComplexPhrase.zip, 
 ComplexPhraseQueryParser.java, ComplexPhrase.zip, ComplexPhrase.zip, 
 ComplexPhrase.zip, ComplexPhrase.zip, ComplexPhrase.zip, 
 SOLR-1604-alternative.patch, SOLR-1604.patch, SOLR-1604.patch


 Solr Plugin for ComplexPhraseQueryParser (LUCENE-1486) which supports 
 wildcards, ORs, ranges, fuzzies inside phrase queries.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: Build failed in Jenkins: lucene40-beaster #1327

I'll try to debug this one again. I couldn't reproduce it yesterday,
but maybe this one will work better.

On Thu, Oct 4, 2012 at 10:35 PM,  hudsonsevilt...@gmail.com wrote:
 See http://sierranevada.servebeer.com/job/lucene40-beaster/1327/

 --
 [...truncated 2433 lines...]
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestDocsAndPositions
 [junit4:junit4] Completed on J2 in 0.38s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestMultiFields
 [junit4:junit4] Completed on J0 in 0.18s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestDocTermOrds
 [junit4:junit4] Completed on J1 in 0.14s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestIndexableField
 [junit4:junit4] Completed on J3 in 0.32s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestMultiLevelSkipList
 [junit4:junit4] Completed on J1 in 0.17s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestTermVectorsReader
 [junit4:junit4] Completed on J2 in 0.29s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.similarities.TestSimilarity2
 [junit4:junit4] Completed on J0 in 0.32s, 7 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.automaton.TestBasicOperations
 [junit4:junit4] Completed on J3 in 0.12s, 8 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestRollingBuffer
 [junit4:junit4] Completed on J2 in 0.06s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule
 [junit4:junit4] Completed on J3 in 0.05s, 5 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestOmitPositions
 [junit4:junit4] Completed on J1 in 0.26s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestIdentityHashSet
 [junit4:junit4] Completed on J2 in 0.06s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper
 [junit4:junit4] Completed on J3 in 0.03s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestWildcardRandom
 [junit4:junit4] Completed on J1 in 0.04s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.TestComplexExplanationsOfNonMatches
 [junit4:junit4] Completed on J2 in 0.05s, 22 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestCheckIndex
 [junit4:junit4] Completed on J3 in 0.02s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.spans.TestNearSpansOrdered
 [junit4:junit4] Completed on J1 in 0.11s, 10 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.automaton.TestSpecialOperations
 [junit4:junit4] Completed on J2 in 0.04s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestDocCount
 [junit4:junit4] Completed on J3 in 0.02s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
 [junit4:junit4] Completed on J1 in 0.24s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestUniqueTermCount
 [junit4:junit4] Completed on J2 in 0.07s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.TestSearchForDuplicates
 [junit4:junit4] Completed on J3 in 0.06s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestPerSegmentDeletes
 [junit4:junit4] Completed on J1 in 0.08s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms
 [junit4:junit4] Completed on J2 in 0.02s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex
 [junit4:junit4] Completed on J3 in 0.02s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.document.TestDocument
 [junit4:junit4] Completed on J1 in 0.03s, 10 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestSetOnce
 [junit4:junit4] Completed on J2 in 0.02s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining
 [junit4:junit4] Completed on J3 in 0.02s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestDocIdSet
 [junit4:junit4] Completed on J1 in 0.01s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestSubScorerFreqs
 [junit4:junit4] Completed on J2 in 0.02s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestBooleanOr
 [junit4:junit4] Completed on J0 in 1.93s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.store.TestFileSwitchDirectory
 [junit4:junit4] Completed on J3 in 0.02s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestDateFilter
 [junit4:junit4] Completed on J1 in 0.02s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestMultiTermQueryRewrites
 [junit4:junit4] Completed on J2

[jira] [Created] (LUCENE-4460) Test exception handling better/easier than testThreadInterruptDeadlock()

Robert Muir created LUCENE-4460:
---

 Summary: Test exception handling better/easier than 
testThreadInterruptDeadlock()
 Key: LUCENE-4460
 URL: https://issues.apache.org/jira/browse/LUCENE-4460
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/test
Reporter: Robert Muir


currently the fact that MockDirectoryWrapper has throttlers and such that 
sleep, combined with the fact this test interrupts, makes a good test for 
exception handling.

The problem is this is really crappy to debug: things dont reproduce, you have 
to use hundreds or thousands of iterations, etc etc.

I think it would be better if we made it possible for MockIndexInput to throw 
random exceptions like MockIndexOutput and had a single threaded test that just 
threw random exceptions? This way it would reproduce...


--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3914) Solr 3.6.1 Tutorial links to http://localhost:8983

2012-10-05 Thread Otis Gospodnetic (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3914?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Otis Gospodnetic resolved SOLR-3914.


Resolution: Invalid

[~marcelbecker] these links work once you install and run Solr locally.

 Solr 3.6.1 Tutorial links to http://localhost:8983
 --

 Key: SOLR-3914
 URL: https://issues.apache.org/jira/browse/SOLR-3914
 Project: Solr
  Issue Type: Bug
  Components: documentation
Affects Versions: 3.6.1
Reporter: Marcel Becker
Priority: Minor

 In your documentation (tutorial) at
 http://lucene.apache.org/solr/api-3_6_1/doc-files/tutorial.html
 several links point at 
 http://localhost:8983/solr/
 I'm totally new to your project, thus, I cannot guess what the correct URL 
 would be.
 Thanks a lot for the documentation :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: Build failed in Jenkins: slow-io-beasting #628

Thanks Dawid!

On Fri, Oct 5, 2012 at 3:03 AM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
 This is a race condition error resulting from unsynchronized access to
 a list. Very unlikely to happen but you got it, awesome! I'll fix.

 Dawid

 On Thu, Oct 4, 2012 at 6:45 PM, Dawid Weiss
 dawid.we...@cs.put.poznan.pl wrote:
 See http://sierranevada.servebeer.com:8080/job/slow-io-beasting/628/

 I'll take a look.

 -
 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-3861) Refactor SolrCoreState so that it's managed by SolrCore .

2012-10-05 Thread Mark Miller (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-3861:
--

Priority: Minor  (was: Blocker)

 Refactor SolrCoreState so that it's managed by SolrCore .
 -

 Key: SOLR-3861
 URL: https://issues.apache.org/jira/browse/SOLR-3861
 Project: Solr
  Issue Type: Bug
Reporter: Hoss Man
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.1, 5.0

 Attachments: SOLR-3861.patch, SOLR-3861.patch, SOLR-3861.patch


 SOLR-2008 fixed a possible RejectedExecutionException by ensuring that 
 SolrCore closed the updateHandler before the searcherExecutor.
 [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is 
 annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's 
 not clear why - pretty sure this means that the risk of a Rejected exception 
 is back in 4.0-BETA...
 https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: Build failed in Jenkins: lucene40-beaster #1327

I can't reproduce this one with a lot of iterations, but I think I see
how this can happen. Ill commit
some cleanups to the exception handling here with lots of TODOs and
hope for the best.

On Fri, Oct 5, 2012 at 9:33 AM, Robert Muir rcm...@gmail.com wrote:
 I'll try to debug this one again. I couldn't reproduce it yesterday,
 but maybe this one will work better.

 On Thu, Oct 4, 2012 at 10:35 PM,  hudsonsevilt...@gmail.com wrote:
 See http://sierranevada.servebeer.com/job/lucene40-beaster/1327/

 --
 [...truncated 2433 lines...]
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestDocsAndPositions
 [junit4:junit4] Completed on J2 in 0.38s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestMultiFields
 [junit4:junit4] Completed on J0 in 0.18s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestDocTermOrds
 [junit4:junit4] Completed on J1 in 0.14s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestIndexableField
 [junit4:junit4] Completed on J3 in 0.32s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestMultiLevelSkipList
 [junit4:junit4] Completed on J1 in 0.17s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestTermVectorsReader
 [junit4:junit4] Completed on J2 in 0.29s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.similarities.TestSimilarity2
 [junit4:junit4] Completed on J0 in 0.32s, 7 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.automaton.TestBasicOperations
 [junit4:junit4] Completed on J3 in 0.12s, 8 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestRollingBuffer
 [junit4:junit4] Completed on J2 in 0.06s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule
 [junit4:junit4] Completed on J3 in 0.05s, 5 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestOmitPositions
 [junit4:junit4] Completed on J1 in 0.26s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestIdentityHashSet
 [junit4:junit4] Completed on J2 in 0.06s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.spans.TestSpanMultiTermQueryWrapper
 [junit4:junit4] Completed on J3 in 0.03s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestWildcardRandom
 [junit4:junit4] Completed on J1 in 0.04s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.search.TestComplexExplanationsOfNonMatches
 [junit4:junit4] Completed on J2 in 0.05s, 22 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestCheckIndex
 [junit4:junit4] Completed on J3 in 0.02s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.spans.TestNearSpansOrdered
 [junit4:junit4] Completed on J1 in 0.11s, 10 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.automaton.TestSpecialOperations
 [junit4:junit4] Completed on J2 in 0.04s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestDocCount
 [junit4:junit4] Completed on J3 in 0.02s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestSumDocFreq
 [junit4:junit4] Completed on J1 in 0.24s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestUniqueTermCount
 [junit4:junit4] Completed on J2 in 0.07s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.TestSearchForDuplicates
 [junit4:junit4] Completed on J3 in 0.06s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestPerSegmentDeletes
 [junit4:junit4] Completed on J1 in 0.08s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestBinaryTerms
 [junit4:junit4] Completed on J2 in 0.02s, 1 test
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.index.TestParallelReaderEmptyIndex
 [junit4:junit4] Completed on J3 in 0.02s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.document.TestDocument
 [junit4:junit4] Completed on J1 in 0.03s, 10 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.util.TestSetOnce
 [junit4:junit4] Completed on J2 in 0.02s, 4 tests
 [junit4:junit4]
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining
 [junit4:junit4] Completed on J3 in 0.02s, 2 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestDocIdSet
 [junit4:junit4] Completed on J1 in 0.01s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestSubScorerFreqs
 [junit4:junit4] Completed on J2 in 0.02s, 3 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.search.TestBooleanOr
 [junit4:junit4] Completed on J0 in 1.93s, 6 tests
 [junit4:junit4]
 [junit4:junit4] Suite: org.apache.lucene.store.TestFileSwitchDirectory
 [junit4:junit4] Completed on J3 in 0.02s, 4

[jira] [Updated] (SOLR-3855) DocValues support


 [ 
https://issues.apache.org/jira/browse/SOLR-3855?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adrien Grand updated SOLR-3855:
---

Attachment: SOLR-3855.patch

Initial patch:

DocValues can be:
 - configured on a per-field-type basis (docValueType=...),
 - enabled on a per-field basis (docValues=true/false)

and are available for the following field types:
 - StrField,
 - UUIDField,
 - Trie*Field,
 - BoolField.

When doc values are enabled, they have precedence over the field cache for 
{{getValueSource}} and {{getSortField}}, however faceting and stats cannot use 
doc values yet (I would like to do this as a separate issue).

I force fields that have doc values enabled to be single-valued and to be 
either required or have a default value.

I also modified a lot of code (ReturnFields especially) to make DocValues 
behave like stored fields. I think this would be great for ID fields. In a 
cluster that has {{numShards}} shards, it would help decrease the number of 
disk seeks in the .fdt file (which is often too big to fit entirely in the OS 
cache) per request from {{(numShards * (start + rows) + rows)}} to {{rows}}.

The patch is not committable yet, and I have 
{{BasicDistributedZkTest.testDistribSearch}} that always fails (not sure why 
yet...) but I'd love to have some feedback to know whether it is going in the 
right direction.

 DocValues support
 -

 Key: SOLR-3855
 URL: https://issues.apache.org/jira/browse/SOLR-3855
 Project: Solr
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.1, 5.0

 Attachments: SOLR-3855.patch


 It would be nice if Solr supported DocValues:
  - for ID fields (fewer disk seeks when running distributed search),
  - for sorting/faceting/function queries (faster warmup time than fieldcache),
  - better on-disk and in-memory efficiency (you can use packed impls).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (LUCENE-4426) New ValueSource implementations that wrap DocValues


 [ 
https://issues.apache.org/jira/browse/LUCENE-4426?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Adrien Grand resolved LUCENE-4426.
--

Resolution: Fixed

Committed (r1394513 on trunk and r1394529 on the 4.x branch).

 New ValueSource implementations that wrap DocValues
 ---

 Key: LUCENE-4426
 URL: https://issues.apache.org/jira/browse/LUCENE-4426
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/other
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.1, 5.0

 Attachments: LUCENE-4426.patch, LUCENE-4426.patch, LUCENE-4426.patch


 We should have ValueSource implementations that wrap DocValues in 
 lucene-queries so that DocValues can be used in function queries.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3915) Color Legend for Cloud UI

2012-10-05 Thread Stefan Matheis (steffkes) (JIRA)

Stefan Matheis (steffkes) created SOLR-3915:
---

 Summary: Color Legend for Cloud UI
 Key: SOLR-3915
 URL: https://issues.apache.org/jira/browse/SOLR-3915
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
 Fix For: 4.1


The meaning of the used shard colors is not really clear, integrate kind of a 
legend fo all possible node-states.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3602) Look into updating to ZooKeeper 3.4.5

2012-10-05 Thread Mark Miller (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Mark Miller updated SOLR-3602:
--

Summary: Look into updating to ZooKeeper 3.4.5  (was: Look into updating to 
ZooKeeper 3.4.)

 Look into updating to ZooKeeper 3.4.5
 -

 Key: SOLR-3602
 URL: https://issues.apache.org/jira/browse/SOLR-3602
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.1, 5.0


 Looks like 3.4.4 may be considered stable - if that happens, we should look 
 into updating.
 Otherwise, we should keep on eye out for 3.3.6

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3602) Look into updating to ZooKeeper 3.4.5

2012-10-05 Thread Mark Miller (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3602?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470376#comment-13470376
 ] 

Mark Miller commented on SOLR-3602:
---

I'm going to hold off a moment as it looks like 3.4.5 is about to release.

 Look into updating to ZooKeeper 3.4.5
 -

 Key: SOLR-3602
 URL: https://issues.apache.org/jira/browse/SOLR-3602
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Mark Miller
Assignee: Mark Miller
Priority: Minor
 Fix For: 4.1, 5.0


 Looks like 3.4.4 may be considered stable - if that happens, we should look 
 into updating.
 Otherwise, we should keep on eye out for 3.3.6

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3915) Color Legend for Cloud UI

2012-10-05 Thread Stefan Matheis (steffkes) (JIRA)


 [ 
https://issues.apache.org/jira/browse/SOLR-3915?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Stefan Matheis (steffkes) updated SOLR-3915:


Attachment: SOLR-3915.patch

First Version, not sure if css's {{text-shadow}} is the best solution, it's 
more blurry than a concrete outline like the graph has one .. will see if i can 
get the same markup for the legend.

 Color Legend for Cloud UI
 -

 Key: SOLR-3915
 URL: https://issues.apache.org/jira/browse/SOLR-3915
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
 Fix For: 4.1

 Attachments: SOLR-3915.patch


 The meaning of the used shard colors is not really clear, integrate kind of a 
 legend fo all possible node-states.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (LUCENE-4461) Multiple FacetRequest with the same path creates inconsistent results

Rodrigo Vega created LUCENE-4461:


 Summary: Multiple FacetRequest with the same path creates 
inconsistent results
 Key: LUCENE-4461
 URL: https://issues.apache.org/jira/browse/LUCENE-4461
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/facet
Affects Versions: 3.6
Reporter: Rodrigo Vega


Multiple FacetRequest are getting merged into one creating wrong results in 
this case:

FacetSearchParams facetSearchParams = new FacetSearchParams();
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));

Problem can be fixed defining hashcode and equals in certain way that Lucene 
recognize we are talking about different requests.


A Very simple test case:


public class LuceneFacetTest {

@Test
public void testDuplicateFacetRequest() throws Exception {
IndexWriter writer = new IndexWriter(new RAMDirectory(), new 
IndexWriterConfig(Version.LUCENE_36, new StandardAnalyzer(Version.LUCENE_36)));
Directory taxoDir = new RAMDirectory();
TaxonomyWriter taxoWriter = new 
DirectoryTaxonomyWriter(taxoDir, OpenMode.CREATE);

Document doc = new Document();
doc.add(new Field(title, simple text title, Store.YES, 
org.apache.lucene.document.Field.Index.ANALYZED));
ListCategoryPath categories = new ArrayListCategoryPath();
categories.add(new CategoryPath(author, Mark Twain));
categories.add(new CategoryPath(year, 2010));
CategoryDocumentBuilder categoryDocBuilder = new 
CategoryDocumentBuilder(taxoWriter);
categoryDocBuilder.setCategoryPaths(categories);
categoryDocBuilder.build(doc);
writer.addDocument(doc);
writer.commit();
taxoWriter.commit();

IndexReader indexReader = IndexReader.open(writer, true);
IndexSearcher searcher = new IndexSearcher(indexReader);
TaxonomyReader taxoReader = new 
DirectoryTaxonomyReader(taxoDir);
Query q = new TermQuery(new Term(title, text));

TopScoreDocCollector tdc = TopScoreDocCollector.create(10, 
true);

FacetSearchParams facetSearchParams = new FacetSearchParams();
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));

FacetsCollector facetsCollector = new 
FacetsCollector(facetSearchParams, indexReader, taxoReader);
searcher.search(q, MultiCollector.wrap(tdc, facetsCollector));
ListFacetResult res = facetsCollector.getFacetResults();

Assert.assertEquals(Only Mark Twain should be returned as 
result, 1, res.get(0).getNumValidDescendants());
Assert.assertEquals(Only Mark Twain should be returned as 
result, 1, res.get(1).getNumValidDescendants());
}
}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4461) Multiple FacetRequest with the same path creates inconsistent results


 [ 
https://issues.apache.org/jira/browse/LUCENE-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rodrigo Vega updated LUCENE-4461:
-

Description: 
Multiple FacetRequest are getting merged into one creating wrong results in 
this case:

FacetSearchParams facetSearchParams = new FacetSearchParams();
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));

Problem can be fixed by defining hashcode and equals in certain way that Lucene 
recognize we are talking about different requests.


A Very simple test case:


public class LuceneFacetTest {

@Test
public void testDuplicateFacetRequest() throws Exception {
IndexWriter writer = new IndexWriter(new RAMDirectory(), new 
IndexWriterConfig(Version.LUCENE_36, new StandardAnalyzer(Version.LUCENE_36)));
Directory taxoDir = new RAMDirectory();
TaxonomyWriter taxoWriter = new 
DirectoryTaxonomyWriter(taxoDir, OpenMode.CREATE);

Document doc = new Document();
doc.add(new Field(title, simple text title, Store.YES, 
org.apache.lucene.document.Field.Index.ANALYZED));
ListCategoryPath categories = new ArrayListCategoryPath();
categories.add(new CategoryPath(author, Mark Twain));
categories.add(new CategoryPath(year, 2010));
CategoryDocumentBuilder categoryDocBuilder = new 
CategoryDocumentBuilder(taxoWriter);
categoryDocBuilder.setCategoryPaths(categories);
categoryDocBuilder.build(doc);
writer.addDocument(doc);
writer.commit();
taxoWriter.commit();

IndexReader indexReader = IndexReader.open(writer, true);
IndexSearcher searcher = new IndexSearcher(indexReader);
TaxonomyReader taxoReader = new 
DirectoryTaxonomyReader(taxoDir);
Query q = new TermQuery(new Term(title, text));

TopScoreDocCollector tdc = TopScoreDocCollector.create(10, 
true);

FacetSearchParams facetSearchParams = new FacetSearchParams();
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));

FacetsCollector facetsCollector = new 
FacetsCollector(facetSearchParams, indexReader, taxoReader);
searcher.search(q, MultiCollector.wrap(tdc, facetsCollector));
ListFacetResult res = facetsCollector.getFacetResults();

Assert.assertEquals(Only Mark Twain should be returned as 
result, 1, res.get(0).getNumValidDescendants());
Assert.assertEquals(Only Mark Twain should be returned as 
result, 1, res.get(1).getNumValidDescendants());
}
}

  was:
Multiple FacetRequest are getting merged into one creating wrong results in 
this case:

FacetSearchParams facetSearchParams = new FacetSearchParams();
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));

Problem can be fixed defining hashcode and equals in certain way that Lucene 
recognize we are talking about different requests.


A Very simple test case:


public class LuceneFacetTest {

@Test
public void testDuplicateFacetRequest() throws Exception {
IndexWriter writer = new IndexWriter(new RAMDirectory(), new 
IndexWriterConfig(Version.LUCENE_36, new StandardAnalyzer(Version.LUCENE_36)));
Directory taxoDir = new RAMDirectory();
TaxonomyWriter taxoWriter = new 
DirectoryTaxonomyWriter(taxoDir, OpenMode.CREATE);

Document doc = new Document();
doc.add(new Field(title, simple text title, Store.YES, 
org.apache.lucene.document.Field.Index.ANALYZED));
ListCategoryPath categories = new ArrayListCategoryPath();
categories.add(new CategoryPath(author, Mark Twain));
categories.add(new CategoryPath(year, 2010));
CategoryDocumentBuilder categoryDocBuilder = new 
CategoryDocumentBuilder(taxoWriter);
categoryDocBuilder.setCategoryPaths(categories);
categoryDocBuilder.build(doc);
writer.addDocument(doc);
writer.commit();
taxoWriter.commit();

IndexReader indexReader = IndexReader.open(writer, true);
IndexSearcher searcher = new IndexSearcher(indexReader);
TaxonomyReader taxoReader = new

[jira] [Updated] (LUCENE-4461) Multiple FacetRequest with the same path creates inconsistent results


 [ 
https://issues.apache.org/jira/browse/LUCENE-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rodrigo Vega updated LUCENE-4461:
-

Description: 
Multiple FacetRequest are getting merged into one creating wrong results in 
this case:

FacetSearchParams facetSearchParams = new FacetSearchParams();
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));

Problem can be fixed by defining hashcode and equals in certain way that Lucene 
recognize we are talking about different requests.


Attached test case.

  was:
Multiple FacetRequest are getting merged into one creating wrong results in 
this case:

FacetSearchParams facetSearchParams = new FacetSearchParams();
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));

Problem can be fixed by defining hashcode and equals in certain way that Lucene 
recognize we are talking about different requests.


A Very simple test case:


public class LuceneFacetTest {

@Test
public void testDuplicateFacetRequest() throws Exception {
IndexWriter writer = new IndexWriter(new RAMDirectory(), new 
IndexWriterConfig(Version.LUCENE_36, new StandardAnalyzer(Version.LUCENE_36)));
Directory taxoDir = new RAMDirectory();
TaxonomyWriter taxoWriter = new 
DirectoryTaxonomyWriter(taxoDir, OpenMode.CREATE);

Document doc = new Document();
doc.add(new Field(title, simple text title, Store.YES, 
org.apache.lucene.document.Field.Index.ANALYZED));
ListCategoryPath categories = new ArrayListCategoryPath();
categories.add(new CategoryPath(author, Mark Twain));
categories.add(new CategoryPath(year, 2010));
CategoryDocumentBuilder categoryDocBuilder = new 
CategoryDocumentBuilder(taxoWriter);
categoryDocBuilder.setCategoryPaths(categories);
categoryDocBuilder.build(doc);
writer.addDocument(doc);
writer.commit();
taxoWriter.commit();

IndexReader indexReader = IndexReader.open(writer, true);
IndexSearcher searcher = new IndexSearcher(indexReader);
TaxonomyReader taxoReader = new 
DirectoryTaxonomyReader(taxoDir);
Query q = new TermQuery(new Term(title, text));

TopScoreDocCollector tdc = TopScoreDocCollector.create(10, 
true);

FacetSearchParams facetSearchParams = new FacetSearchParams();
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));
facetSearchParams.addFacetRequest(new CountFacetRequest(new 
CategoryPath(author), 10));

FacetsCollector facetsCollector = new 
FacetsCollector(facetSearchParams, indexReader, taxoReader);
searcher.search(q, MultiCollector.wrap(tdc, facetsCollector));
ListFacetResult res = facetsCollector.getFacetResults();

Assert.assertEquals(Only Mark Twain should be returned as 
result, 1, res.get(0).getNumValidDescendants());
Assert.assertEquals(Only Mark Twain should be returned as 
result, 1, res.get(1).getNumValidDescendants());
}
}


 Multiple FacetRequest with the same path creates inconsistent results
 -

 Key: LUCENE-4461
 URL: https://issues.apache.org/jira/browse/LUCENE-4461
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/facet
Affects Versions: 3.6
Reporter: Rodrigo Vega
  Labels: facet, faceted-search
 Attachments: LuceneFacetTest.java


 Multiple FacetRequest are getting merged into one creating wrong results in 
 this case:
 FacetSearchParams facetSearchParams = new FacetSearchParams();
   facetSearchParams.addFacetRequest(new CountFacetRequest(new 
 CategoryPath(author), 10));
   facetSearchParams.addFacetRequest(new CountFacetRequest(new 
 CategoryPath(author), 10));
 Problem can be fixed by defining hashcode and equals in certain way that 
 Lucene recognize we are talking about different requests.
 Attached test case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional

[jira] [Updated] (LUCENE-4461) Multiple FacetRequest with the same path creates inconsistent results


 [ 
https://issues.apache.org/jira/browse/LUCENE-4461?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Rodrigo Vega updated LUCENE-4461:
-

Attachment: LuceneFacetTest.java

 Multiple FacetRequest with the same path creates inconsistent results
 -

 Key: LUCENE-4461
 URL: https://issues.apache.org/jira/browse/LUCENE-4461
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/facet
Affects Versions: 3.6
Reporter: Rodrigo Vega
  Labels: facet, faceted-search
 Attachments: LuceneFacetTest.java


 Multiple FacetRequest are getting merged into one creating wrong results in 
 this case:
 FacetSearchParams facetSearchParams = new FacetSearchParams();
   facetSearchParams.addFacetRequest(new CountFacetRequest(new 
 CategoryPath(author), 10));
   facetSearchParams.addFacetRequest(new CountFacetRequest(new 
 CategoryPath(author), 10));
 Problem can be fixed by defining hashcode and equals in certain way that 
 Lucene recognize we are talking about different requests.
 Attached test case.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4226) Efficient compression of small to medium stored fields


[ 
https://issues.apache.org/jira/browse/LUCENE-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470392#comment-13470392
 ] 

Adrien Grand commented on LUCENE-4226:
--

I just committed to trunk. I'll wait for a couple of days to make sure Jenkins 
builds pass before backporting to 4.x. By the way, would it be possible to have 
one of the Jenkins servers to run lucene-core tests with 
-Dtests.codec=Compressing for some time?

 Efficient compression of small to medium stored fields
 --

 Key: LUCENE-4226
 URL: https://issues.apache.org/jira/browse/LUCENE-4226
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/index
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Trivial
 Fix For: 4.1, 5.0

 Attachments: CompressionBenchmark.java, CompressionBenchmark.java, 
 LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch, 
 LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch, 
 SnappyCompressionAlgorithm.java


 I've been doing some experiments with stored fields lately. It is very common 
 for an index with stored fields enabled to have most of its space used by the 
 .fdt index file. To prevent this .fdt file from growing too much, one option 
 is to compress stored fields. Although compression works rather well for 
 large fields, this is not the case for small fields and the compression ratio 
 can be very close to 100%, even with efficient compression algorithms.
 In order to improve the compression ratio for small fields, I've written a 
 {{StoredFieldsFormat}} that compresses several documents in a single chunk of 
 data. To see how it behaves in terms of document deserialization speed and 
 compression ratio, I've run several tests with different index compression 
 strategies on 100,000 docs from Mike's 1K Wikipedia articles (title and text 
 were indexed and stored):
  - no compression,
  - docs compressed with deflate (compression level = 1),
  - docs compressed with deflate (compression level = 9),
  - docs compressed with Snappy,
  - using the compressing {{StoredFieldsFormat}} with deflate (level = 1) and 
 chunks of 6 docs,
  - using the compressing {{StoredFieldsFormat}} with deflate (level = 9) and 
 chunks of 6 docs,
  - using the compressing {{StoredFieldsFormat}} with Snappy and chunks of 6 
 docs.
 For those who don't know Snappy, it is compression algorithm from Google 
 which has very high compression ratios, but compresses and decompresses data 
 very quickly.
 {noformat}
 Format   Compression ratio IndexReader.document time
 
 uncompressed 100%  100%
 doc/deflate 1 59%  616%
 doc/deflate 9 58%  595%
 doc/snappy80%  129%
 index/deflate 1   49%  966%
 index/deflate 9   46%  938%
 index/snappy  65%  264%
 {noformat}
 (doc = doc-level compression, index = index-level compression)
 I find it interesting because it allows to trade speed for space (with 
 deflate, the .fdt file shrinks by a factor of 2, much better than with 
 doc-level compression). One other interesting thing is that {{index/snappy}} 
 is almost as compact as {{doc/deflate}} while it is more than 2x faster at 
 retrieving documents from disk.
 These tests have been done on a hot OS cache, which is the worst case for 
 compressed fields (one can expect better results for formats that have a high 
 compression ratio since they probably require fewer read/write operations 
 from disk).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3915) Color Legend for Cloud UI

2012-10-05 Thread Jack Krupansky (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3915?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470404#comment-13470404
 ] 

Jack Krupansky commented on SOLR-3915:
--

Can you document the legend in text here so that people with 4.0 have at least 
some reference they can consult?

 Color Legend for Cloud UI
 -

 Key: SOLR-3915
 URL: https://issues.apache.org/jira/browse/SOLR-3915
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
 Fix For: 4.1

 Attachments: SOLR-3915.patch


 The meaning of the used shard colors is not really clear, integrate kind of a 
 legend fo all possible node-states.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4460) Test exception handling better/easier than testThreadInterruptDeadlock()


[ 
https://issues.apache.org/jira/browse/LUCENE-4460?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470425#comment-13470425
 ] 

Michael McCandless commented on LUCENE-4460:


+1

 Test exception handling better/easier than testThreadInterruptDeadlock()
 

 Key: LUCENE-4460
 URL: https://issues.apache.org/jira/browse/LUCENE-4460
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/test
Reporter: Robert Muir

 currently the fact that MockDirectoryWrapper has throttlers and such that 
 sleep, combined with the fact this test interrupts, makes a good test for 
 exception handling.
 The problem is this is really crappy to debug: things dont reproduce, you 
 have to use hundreds or thousands of iterations, etc etc.
 I think it would be better if we made it possible for MockIndexInput to throw 
 random exceptions like MockIndexOutput and had a single threaded test that 
 just threw random exceptions? This way it would reproduce...

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4399) Rename AppendingCodec to Appending40Codec


[ 
https://issues.apache.org/jira/browse/LUCENE-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470431#comment-13470431
 ] 

Michael McCandless commented on LUCENE-4399:


+1

 Rename AppendingCodec to Appending40Codec
 -

 Key: LUCENE-4399
 URL: https://issues.apache.org/jira/browse/LUCENE-4399
 Project: Lucene - Core
  Issue Type: New Feature
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Minor
 Fix For: 4.1

 Attachments: LUCENE-4399.patch, LUCENE-4399.patch, LUCENE-4399.patch, 
 LUCENE-4399.patch


 In order AppendingCodec to follow Lucene codecs version, I think its name 
 should include a version number (so that, for example, if we get to releave 
 Lucene 4.3 with a new Lucene43Codec, there will also be a new 
 Appending43Codec).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: StandardTokenizer generation from JFlex grammar

2012-10-05 Thread vempap

I'm using a wrong jflex version. need to use the version from the trunk



--
View this message in context: 
http://lucene.472066.n3.nabble.com/StandardTokenizer-generation-from-JFlex-grammar-tp4011939p4012094.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_07) - Build # 1555 - Failure!

2012-10-05 Thread Policeman Jenkins Server

Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/1555/
Java: 32bit/jdk1.7.0_07 -client -XX:+UseParallelGC

1 tests failed.
REGRESSION:  org.apache.lucene.queries.function.TestDocValuesFieldSources.test

Error Message:
codec=Lucene3x does not support docValues: from 
docValuesFormat().docsConsumer(...) returned null; field=id

Stack Trace:
java.lang.IllegalStateException: codec=Lucene3x does not support docValues: 
from docValuesFormat().docsConsumer(...) returned null; field=id
at 
__randomizedtesting.SeedInfo.seed([D04DEF927E66B7EF:5819D048D09ADA17]:0)
at 
org.apache.lucene.index.DocFieldProcessor.docValuesConsumer(DocFieldProcessor.java:362)
at 
org.apache.lucene.index.DocFieldProcessor.processDocument(DocFieldProcessor.java:275)
at 
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:244)
at 
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:373)
at 
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1445)
at 
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1124)
at 
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:201)
at 
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:160)
at 
org.apache.lucene.queries.function.TestDocValuesFieldSources.test(TestDocValuesFieldSources.java:152)
at 
org.apache.lucene.queries.function.TestDocValuesFieldSources.test(TestDocValuesFieldSources.java:279)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at

Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_07) - Build # 1555 - Failure!

In 4.x we need a @SuppressCodecs here, ill fix it

On Fri, Oct 5, 2012 at 12:54 PM, Policeman Jenkins Server
jenk...@sd-datasolutions.de wrote:
 Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/1555/
 Java: 32bit/jdk1.7.0_07 -client -XX:+UseParallelGC

 1 tests failed.
 REGRESSION:  org.apache.lucene.queries.function.TestDocValuesFieldSources.test

 Error Message:
 codec=Lucene3x does not support docValues: from 
 docValuesFormat().docsConsumer(...) returned null; field=id

 Stack Trace:
 java.lang.IllegalStateException: codec=Lucene3x does not support docValues: 
 from docValuesFormat().docsConsumer(...) returned null; field=id
 at 
 __randomizedtesting.SeedInfo.seed([D04DEF927E66B7EF:5819D048D09ADA17]:0)
 at 
 org.apache.lucene.index.DocFieldProcessor.docValuesConsumer(DocFieldProcessor.java:362)
 at 
 org.apache.lucene.index.DocFieldProcessor.processDocument(DocFieldProcessor.java:275)
 at 
 org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:244)
 at 
 org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:373)
 at 
 org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1445)
 at 
 org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1124)
 at 
 org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:201)
 at 
 org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:160)
 at 
 org.apache.lucene.queries.function.TestDocValuesFieldSources.test(TestDocValuesFieldSources.java:152)
 at 
 org.apache.lucene.queries.function.TestDocValuesFieldSources.test(TestDocValuesFieldSources.java:279)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
 at 
 org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
 at 
 org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
 at 
 com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
 at 
 org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
 at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
 at 
 com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
 at

Storing html files in lucene index

2012-10-05 Thread rajputadesh

Hi to all I am using Apache Lucene in java Swing API . For searching i am
indexing on the contents of html files  
But the problem is that i have to give the complete software to the client
and we dont want to give the actual html files but they should be stored in
lucene index. and on client side he could access them only with the help of
lucene index . 
Is it possible in lucene if yes then please suggest me the code of storing
as well accessing the html files on client side
regards
thanks in advance



--
View this message in context: 
http://lucene.472066.n3.nabble.com/Storing-html-files-in-lucene-index-tp4012002.html
Sent from the Lucene - Java Developer mailing list archive at Nabble.com.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3914) Solr 3.6.1 Tutorial links to http://localhost:8983


[ 
https://issues.apache.org/jira/browse/SOLR-3914?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470506#comment-13470506
 ] 

Hoss Man commented on SOLR-3914:


More specifically, the beginning of the tutorial explicitly states...

bq. Please run the browser showing this tutorial and the Solr server on the 
same machine so tutorial links will correctly point to your Solr server. 

 Solr 3.6.1 Tutorial links to http://localhost:8983
 --

 Key: SOLR-3914
 URL: https://issues.apache.org/jira/browse/SOLR-3914
 Project: Solr
  Issue Type: Bug
  Components: documentation
Affects Versions: 3.6.1
Reporter: Marcel Becker
Priority: Minor

 In your documentation (tutorial) at
 http://lucene.apache.org/solr/api-3_6_1/doc-files/tutorial.html
 several links point at 
 http://localhost:8983/solr/
 I'm totally new to your project, thus, I cannot guess what the correct URL 
 would be.
 Thanks a lot for the documentation :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4226) Efficient compression of small to medium stored fields

2012-10-05 Thread Simon Willnauer (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470509#comment-13470509
 ] 

Simon Willnauer commented on LUCENE-4226:
-

bq. By the way, would it be possible to have one of the Jenkins servers to run 
lucene-core tests with -Dtests.codec=Compressing for some time?

FYI - 
http://builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only-compressed/

 Efficient compression of small to medium stored fields
 --

 Key: LUCENE-4226
 URL: https://issues.apache.org/jira/browse/LUCENE-4226
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/index
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Trivial
 Fix For: 4.1, 5.0

 Attachments: CompressionBenchmark.java, CompressionBenchmark.java, 
 LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch, 
 LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch, 
 SnappyCompressionAlgorithm.java


 I've been doing some experiments with stored fields lately. It is very common 
 for an index with stored fields enabled to have most of its space used by the 
 .fdt index file. To prevent this .fdt file from growing too much, one option 
 is to compress stored fields. Although compression works rather well for 
 large fields, this is not the case for small fields and the compression ratio 
 can be very close to 100%, even with efficient compression algorithms.
 In order to improve the compression ratio for small fields, I've written a 
 {{StoredFieldsFormat}} that compresses several documents in a single chunk of 
 data. To see how it behaves in terms of document deserialization speed and 
 compression ratio, I've run several tests with different index compression 
 strategies on 100,000 docs from Mike's 1K Wikipedia articles (title and text 
 were indexed and stored):
  - no compression,
  - docs compressed with deflate (compression level = 1),
  - docs compressed with deflate (compression level = 9),
  - docs compressed with Snappy,
  - using the compressing {{StoredFieldsFormat}} with deflate (level = 1) and 
 chunks of 6 docs,
  - using the compressing {{StoredFieldsFormat}} with deflate (level = 9) and 
 chunks of 6 docs,
  - using the compressing {{StoredFieldsFormat}} with Snappy and chunks of 6 
 docs.
 For those who don't know Snappy, it is compression algorithm from Google 
 which has very high compression ratios, but compresses and decompresses data 
 very quickly.
 {noformat}
 Format   Compression ratio IndexReader.document time
 
 uncompressed 100%  100%
 doc/deflate 1 59%  616%
 doc/deflate 9 58%  595%
 doc/snappy80%  129%
 index/deflate 1   49%  966%
 index/deflate 9   46%  938%
 index/snappy  65%  264%
 {noformat}
 (doc = doc-level compression, index = index-level compression)
 I find it interesting because it allows to trade speed for space (with 
 deflate, the .fdt file shrinks by a factor of 2, much better than with 
 doc-level compression). One other interesting thing is that {{index/snappy}} 
 is almost as compact as {{doc/deflate}} while it is more than 2x faster at 
 retrieving documents from disk.
 These tests have been done on a hot OS cache, which is the worst case for 
 compressed fields (one can expect better results for formats that have a high 
 compression ratio since they probably require fewer read/write operations 
 from disk).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-Linux-Java6-64-test-only-compressed - Build # 1 - Failure!

2012-10-05 Thread builder

Build: 
builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only-compressed/1/

No tests ran.

Build Log:
[...truncated 7323 lines...]
ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/dev/nightly
org.tmatesoft.svn.core.SVNException: svn: 
'/repos/asf/!svn/bc/1394703/lucene/dev/nightly' path not found: 404 Not Found 
(http://svn.apache.org)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
at 
org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLocationsImpl(DAVRepository.java:1059)
at 
org.tmatesoft.svn.core.io.SVNRepository.getLocations(SVNRepository.java:1087)
at 
org.tmatesoft.svn.core.io.SVNRepository.getLocations(SVNRepository.java:1515)
at 
org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:903)
at 
org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534)
at 
org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:901)
at 
hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:84)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
at 
hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
at 
hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:788)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:769)
at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
at hudson.FilePath.act(FilePath.java:842)
at hudson.FilePath.act(FilePath.java:824)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1249)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494)
at hudson.model.Run.execute(Run.java:1488)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)
Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: 
'/repos/asf/!svn/bc/1394703/lucene/dev/nightly' path not found: 404 Not Found 
(http://svn.apache.org)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:181)
at 
org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:133)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:444)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:288)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:213)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:379)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:292)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:283)
at 
org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:271)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:283)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:274)
at 
org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLocationsImpl(DAVRepository.java:1053)
... 25 more
FATAL: null
java.lang.NullPointerException
at java.util.ArrayList.addAll(ArrayList.java:530)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
at hudson.model.AbstractProject.checkout(AbstractProject.java:1249)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589)
at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
at 
hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494)
at hudson.model.Run.execute(Run.java:1488)
at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
at hudson.model.ResourceController.execute(ResourceController.java:88)
at hudson.model.Executor.run(Executor.java:236)

Re: [JENKINS] Lucene-trunk-Linux-Java6-64-test-only-compressed - Build # 1 - Failure!

2012-10-05 Thread Simon Willnauer

sorry for the noise!

On Fri, Oct 5, 2012 at 8:11 PM,  buil...@flonkings.com wrote:
 Build: 
 builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only-compressed/1/

 No tests ran.

 Build Log:
 [...truncated 7323 lines...]
 ERROR: Failed to check out http://svn.apache.org/repos/asf/lucene/dev/nightly
 org.tmatesoft.svn.core.SVNException: svn: 
 '/repos/asf/!svn/bc/1394703/lucene/dev/nightly' path not found: 404 Not Found 
 (http://svn.apache.org)
 at 
 org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64)
 at 
 org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51)
 at 
 org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLocationsImpl(DAVRepository.java:1059)
 at 
 org.tmatesoft.svn.core.io.SVNRepository.getLocations(SVNRepository.java:1087)
 at 
 org.tmatesoft.svn.core.io.SVNRepository.getLocations(SVNRepository.java:1515)
 at 
 org.tmatesoft.svn.core.wc.SVNBasicClient.getLocations(SVNBasicClient.java:903)
 at 
 org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:534)
 at 
 org.tmatesoft.svn.core.wc.SVNUpdateClient.doCheckout(SVNUpdateClient.java:901)
 at 
 hudson.scm.subversion.CheckoutUpdater$1.perform(CheckoutUpdater.java:84)
 at 
 hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
 at 
 hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:144)
 at 
 hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:121)
 at 
 hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136)
 at 
 hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:788)
 at 
 hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:769)
 at 
 hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753)
 at hudson.FilePath.act(FilePath.java:842)
 at hudson.FilePath.act(FilePath.java:824)
 at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
 at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
 at hudson.model.AbstractProject.checkout(AbstractProject.java:1249)
 at 
 hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589)
 at 
 jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
 at 
 hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494)
 at hudson.model.Run.execute(Run.java:1488)
 at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46)
 at hudson.model.ResourceController.execute(ResourceController.java:88)
 at hudson.model.Executor.run(Executor.java:236)
 Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: 
 '/repos/asf/!svn/bc/1394703/lucene/dev/nightly' path not found: 404 Not Found 
 (http://svn.apache.org)
 at 
 org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200)
 at 
 org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:181)
 at 
 org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:133)
 at 
 org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:444)
 at 
 org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:288)
 at 
 org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:213)
 at 
 org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:379)
 at 
 org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:292)
 at 
 org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:283)
 at 
 org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:271)
 at 
 org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:283)
 at 
 org.tmatesoft.svn.core.internal.io.dav.DAVConnection.doReport(DAVConnection.java:274)
 at 
 org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getLocationsImpl(DAVRepository.java:1053)
 ... 25 more
 FATAL: null
 java.lang.NullPointerException
 at java.util.ArrayList.addAll(ArrayList.java:530)
 at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743)
 at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685)
 at hudson.model.AbstractProject.checkout(AbstractProject.java:1249)
 at 
 hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589)
 at 
 jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88)
 at 
 hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494)
 at hudson.model.Run.execute(Run.java:1488)
 at

[JENKINS] Lucene-trunk-Linux-Java6-64-test-only-compressed - Build # 2 - Still Failing!

2012-10-05 Thread builder

Build: 
builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-test-only-compressed/2/

All tests passed

Build Log:
[...truncated 1060 lines...]
ERROR: No artifacts found that match the file pattern heapdumps/**. 
Configuration error?
ERROR: 'heapdumps/**' doesn't match anything, but '**' does. Perhaps that's 
what you mean?
Build step 'Archive the artifacts' changed build result to FAILURE
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[JENKINS] Lucene-trunk-Linux-Java6-64-o.a.l.index-test-only - Build # 1 - Failure!

2012-10-05 Thread builder

Build: 
builds.flonkings.com/job/Lucene-trunk-Linux-Java6-64-o.a.l.index-test-only/1/

All tests passed

Build Log:
[...truncated 8544 lines...]
ERROR: No artifacts found that match the file pattern heapdumps/**. 
Configuration error?
ERROR: 'heapdumps/**' doesn't match anything, but '**' does. Perhaps that's 
what you mean?
Build step 'Archive the artifacts' changed build result to FAILURE
Recording test results
Email was triggered for: Failure
Sending email for trigger: Failure




-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Storing html files in lucene index

2012-10-05 Thread Erick Erickson

Please ask the question on the user's list, this list is for discussing
coding of Solr and Lucene...

See the Solr User List here:

http://lucene.apache.org/solr/discussion.html

Best
Erick

On Fri, Oct 5, 2012 at 6:05 AM, rajputadesh rajputad...@gmail.com wrote:
 Hi to all I am using Apache Lucene in java Swing API . For searching i am
 indexing on the contents of html files
 But the problem is that i have to give the complete software to the client
 and we dont want to give the actual html files but they should be stored in
 lucene index. and on client side he could access them only with the help of
 lucene index .
 Is it possible in lucene if yes then please suggest me the code of storing
 as well accessing the html files on client side
 regards
 thanks in advance



 --
 View this message in context: 
 http://lucene.472066.n3.nabble.com/Storing-html-files-in-lucene-index-tp4012002.html
 Sent from the Lucene - Java Developer mailing list archive at Nabble.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

Re: [JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 54 - Failure

I committed a fix ... this was actually a real bug, not a test bug,
and my commit is just a workaround.

There seems to be a starvation issue that can allow multiple indexing
threads to flush segments faster than the single thread can publish
them.  I think the problem is that publishing is actually somewhat
costly (creates CFS, writes .si file, etc.), so somehow we need to
make these steps concurrent too ... I'll open an issue for a longer
term fix.

Mike McCandless

http://blog.mikemccandless.com

On Fri, Oct 5, 2012 at 8:03 AM, Michael McCandless
luc...@mikemccandless.com wrote:
 TestBagOfPostings timed out: it got maxBuffereDocs 2 and the
 AlcoholicMergePolicy!!  A bad combination ... I'll change it to
 increase maxBufferedDocs ...

 Mike McCandless

 http://blog.mikemccandless.com

 On Fri, Oct 5, 2012 at 4:21 AM, Apache Jenkins Server
 jenk...@builds.apache.org wrote:
 Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/54/

 6 tests failed.
 REGRESSION:  org.apache.lucene.index.TestBagOfPostings.test

 Error Message:
 Test abandoned because suite timeout was reached.

 Stack Trace:
 java.lang.Exception: Test abandoned because suite timeout was reached.
 at __randomizedtesting.SeedInfo.seed([88207056F447E506]:0)


 FAILED:  junit.framework.TestSuite.org.apache.lucene.index.TestBagOfPostings

 Error Message:
 Suite timeout exceeded (= 720 msec).

 Stack Trace:
 java.lang.Exception: Suite timeout exceeded (= 720 msec).
 at __randomizedtesting.SeedInfo.seed([88207056F447E506]:0)


 REGRESSION:  
 org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule.testRuleInvariantBeforeClass

 Error Message:
 expected:1 but was:0

 Stack Trace:
 java.lang.AssertionError: expected:1 but was:0
 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.util.junitcompat.TestSystemPropertiesInvariantRule.testRuleInvariantBeforeClass(TestSystemPropertiesInvariantRule.java:114)
 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 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
 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.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
 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.runners.ParentRunner.run(ParentRunner.java:300)
 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:161)
 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:255)
 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)


 REGRESSION:  
 org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule.testRuleInvariantAfterClass

 Error Message:
 expected:1 but was:0

 Stack Trace:
 java.lang.AssertionError: expected:1 but was:0
 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.util.junitcompat.TestSystemPropertiesInvariantRule.testRuleInvariantAfterClass(TestSystemPropertiesInvariantRule.java:123)
 at

Re: [JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 54 - Failure

2012-10-05 Thread Simon Willnauer

On Fri, Oct 5, 2012 at 8:27 PM, Michael McCandless
luc...@mikemccandless.com wrote:
 I committed a fix ... this was actually a real bug, not a test bug,
 and my commit is just a workaround.

 There seems to be a starvation issue that can allow multiple indexing
 threads to flush segments faster than the single thread can publish
 them.  I think the problem is that publishing is actually somewhat
 costly (creates CFS, writes .si file, etc.), so somehow we need to
 make these steps concurrent too ... I'll open an issue for a longer
 term fix.
hoho! looking forward to that!

simon



 Mike McCandless

 http://blog.mikemccandless.com

 On Fri, Oct 5, 2012 at 8:03 AM, Michael McCandless
 luc...@mikemccandless.com wrote:
 TestBagOfPostings timed out: it got maxBuffereDocs 2 and the
 AlcoholicMergePolicy!!  A bad combination ... I'll change it to
 increase maxBufferedDocs ...

 Mike McCandless

 http://blog.mikemccandless.com

 On Fri, Oct 5, 2012 at 4:21 AM, Apache Jenkins Server
 jenk...@builds.apache.org wrote:
 Build: https://builds.apache.org/job/Lucene-Solr-NightlyTests-trunk/54/

 6 tests failed.
 REGRESSION:  org.apache.lucene.index.TestBagOfPostings.test

 Error Message:
 Test abandoned because suite timeout was reached.

 Stack Trace:
 java.lang.Exception: Test abandoned because suite timeout was reached.
 at __randomizedtesting.SeedInfo.seed([88207056F447E506]:0)


 FAILED:  junit.framework.TestSuite.org.apache.lucene.index.TestBagOfPostings

 Error Message:
 Suite timeout exceeded (= 720 msec).

 Stack Trace:
 java.lang.Exception: Suite timeout exceeded (= 720 msec).
 at __randomizedtesting.SeedInfo.seed([88207056F447E506]:0)


 REGRESSION:  
 org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule.testRuleInvariantBeforeClass

 Error Message:
 expected:1 but was:0

 Stack Trace:
 java.lang.AssertionError: expected:1 but was:0
 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.util.junitcompat.TestSystemPropertiesInvariantRule.testRuleInvariantBeforeClass(TestSystemPropertiesInvariantRule.java:114)
 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 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
 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.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
 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.runners.ParentRunner.run(ParentRunner.java:300)
 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:161)
 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:255)
 at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)


 REGRESSION:  
 org.apache.lucene.util.junitcompat.TestSystemPropertiesInvariantRule.testRuleInvariantAfterClass

 Error Message:
 expected:1 but was:0

 Stack Trace:
 java.lang.AssertionError: expected:1 but was:0
 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

Re: [JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 54 - Failure

On Fri, Oct 5, 2012 at 2:30 PM, Simon Willnauer
simon.willna...@gmail.com wrote:
 On Fri, Oct 5, 2012 at 8:27 PM, Michael McCandless
 luc...@mikemccandless.com wrote:
 I committed a fix ... this was actually a real bug, not a test bug,
 and my commit is just a workaround.

 There seems to be a starvation issue that can allow multiple indexing
 threads to flush segments faster than the single thread can publish
 them.  I think the problem is that publishing is actually somewhat
 costly (creates CFS, writes .si file, etc.), so somehow we need to
 make these steps concurrent too ... I'll open an issue for a longer
 term fix.
 hoho! looking forward to that!

I'm just going to open the issue :)

Not sure how to fix it ...

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] [Created] (LUCENE-4462) Publishing flushed segments is single threaded and too costly

Michael McCandless created LUCENE-4462:
--

 Summary: Publishing flushed segments is single threaded and too 
costly
 Key: LUCENE-4462
 URL: https://issues.apache.org/jira/browse/LUCENE-4462
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless


Spinoff from http://lucene.markmail.org/thread/4li6bbomru35qn7w

The new TestBagOfPostings failed the build because it timed out after 2 hours 
... but in digging I found that it was a starvation issue: the 4 threads were 
flushing segments much faster than the 1 thread could publish them.

I think this is because publishing segments 
(DocumentsWriter.publishFlushedSegment) is actually rather costly (creates CFS 
file if necessary, writes .si, etc.).

I committed a workaround for now, to prevent starvation (see svn diff -c 
1394704 https://svn.apache.org/repos/asf/lucene/dev/trunk), but we really 
should address the root cause by moving these costly ops into flush() so that 
publishing is a low cost operation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3916) fl parsing is sensitive to newlines at the end of field names

Hoss Man created SOLR-3916:
--

 Summary: fl parsing is sensitive to newlines at the end of field 
names
 Key: SOLR-3916
 URL: https://issues.apache.org/jira/browse/SOLR-3916
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0-BETA
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.0


As reported by giovanni.bricconi on the user list, there is a bug in fl 
parsing that causes solr to get confused when a field name is followed by a 
newline character -- eg: in a requestHandler default like...

{noformat}
!-- newlines showing using $ --$
str name=fl$
   sku,store_slug$  
/str$
{noformat}

...this results in solr assuming it should use function parsing to evaluate the 
field name, which can cause missleading errors if the field name can't be used 
in a function (eg: can not use FieldCache on multivalued field: store_slug)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4285) Improve FST API usability for mere mortals

2012-10-05 Thread David Smiley (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470555#comment-13470555
 ] 

David Smiley commented on LUCENE-4285:
--

I just found out that an FST builder.finish() returns null if there's no input 
basically.  That is bad API design; it should return an FST with nothing init.  
For now I have to have littered null checks.

 Improve FST API usability for mere mortals
 --

 Key: LUCENE-4285
 URL: https://issues.apache.org/jira/browse/LUCENE-4285
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/FSTs
Reporter: David Smiley

 FST technology is something that has brought amazing advances to Lucene, yet 
 the API is hard to use for the vast majority of users like me.  I know that 
 performance of FSTs is really important, but surely a lot can be done without 
 sacrificing that.
 (comments will hold specific ideas and problems)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4462) Publishing flushed segments is single threaded and too costly

2012-10-05 Thread Simon Willnauer (JIRA)


 [ 
https://issues.apache.org/jira/browse/LUCENE-4462?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Simon Willnauer reassigned LUCENE-4462:
---

Assignee: Simon Willnauer

 Publishing flushed segments is single threaded and too costly
 -

 Key: LUCENE-4462
 URL: https://issues.apache.org/jira/browse/LUCENE-4462
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Simon Willnauer

 Spinoff from http://lucene.markmail.org/thread/4li6bbomru35qn7w
 The new TestBagOfPostings failed the build because it timed out after 2 hours 
 ... but in digging I found that it was a starvation issue: the 4 threads were 
 flushing segments much faster than the 1 thread could publish them.
 I think this is because publishing segments 
 (DocumentsWriter.publishFlushedSegment) is actually rather costly (creates 
 CFS file if necessary, writes .si, etc.).
 I committed a workaround for now, to prevent starvation (see svn diff -c 
 1394704 https://svn.apache.org/repos/asf/lucene/dev/trunk), but we really 
 should address the root cause by moving these costly ops into flush() so that 
 publishing is a low cost operation.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: [JENKINS] Lucene-Solr-NightlyTests-trunk - Build # 54 - Failure

OK I opened https://issues.apache.org/jira/browse/LUCENE-4462

Mike McCandless

http://blog.mikemccandless.com


On Fri, Oct 5, 2012 at 2:39 PM, Michael McCandless
luc...@mikemccandless.com wrote:
 On Fri, Oct 5, 2012 at 2:30 PM, Simon Willnauer
 simon.willna...@gmail.com wrote:
 On Fri, Oct 5, 2012 at 8:27 PM, Michael McCandless
 luc...@mikemccandless.com wrote:
 I committed a fix ... this was actually a real bug, not a test bug,
 and my commit is just a workaround.

 There seems to be a starvation issue that can allow multiple indexing
 threads to flush segments faster than the single thread can publish
 them.  I think the problem is that publishing is actually somewhat
 costly (creates CFS, writes .si file, etc.), so somehow we need to
 make these steps concurrent too ... I'll open an issue for a longer
 term fix.
 hoho! looking forward to that!

 I'm just going to open the issue :)

 Not sure how to fix it ...

 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

Solr ResponseBuilder and totalHitCount

2012-10-05 Thread Greg Bowyer

Hi all, I have been off the radar for too long

I am working on a requirement at $DAYJOB where there is a desire to
monitor the rate of low and zero result queries, as such I did the
simplest thing I could think of and wrote a search component that looks
through the response object in the later phases of a distributed request.

As I was doing this it struck me how inconsistent it is to find the
total number of hits for a given search query, even if the response is
manipulated heavily after the fact shouldn't we make it easier for
people writing things like search components / transformers etc to find
out how many matches they had ?

This is where I started to wonder if it makes sense to hide / elide the
original usage of totalHitCount as part of grouping, and use this field
for presenting some sensible number of matches for the query; I know
that this might break backwards compat with people who look at this
field, but then I figure it is very ambiguously named so many naive
users are likely to use this field not realizing that it is all about
grouping.

I am probably going to craft a patch to this end, unless someone has any
intuition that I am missing here

-- Greg

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3916) fl parsing is sensitive to newlines at the end of field names

2012-10-05 Thread Yonik Seeley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470559#comment-13470559
 ] 

Yonik Seeley commented on SOLR-3916:


A lot of things could be confused by this - I don't consider this as much a bug 
in fl parsing as I do a bug in default handling configured via XML.

 fl parsing is sensitive to newlines at the end of field names
 -

 Key: SOLR-3916
 URL: https://issues.apache.org/jira/browse/SOLR-3916
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0-BETA
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.0


 As reported by giovanni.bricconi on the user list, there is a bug in fl 
 parsing that causes solr to get confused when a field name is followed by a 
 newline character -- eg: in a requestHandler default like...
 {noformat}
 !-- newlines showing using $ --$
 str name=fl$
sku,store_slug$  
 /str$
 {noformat}
 ...this results in solr assuming it should use function parsing to evaluate 
 the field name, which can cause missleading errors if the field name can't be 
 used in a function (eg: can not use FieldCache on multivalued field: 
 store_slug)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4285) Improve FST API usability for mere mortals


[ 
https://issues.apache.org/jira/browse/LUCENE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470560#comment-13470560
 ] 

Robert Muir commented on LUCENE-4285:
-

I rather like this: I don't think its common to have an empty FST, its usually 
indicative of a bug or misconfiguration.

There is also some code in lucene that uses this return value, e.g. 
SynonymFilterFactory, if you give it a file with no actual 
synonyms entries it just returns the underlying stream rather than decorating 
it with a useless synonyms filter.

 Improve FST API usability for mere mortals
 --

 Key: LUCENE-4285
 URL: https://issues.apache.org/jira/browse/LUCENE-4285
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/FSTs
Reporter: David Smiley

 FST technology is something that has brought amazing advances to Lucene, yet 
 the API is hard to use for the vast majority of users like me.  I know that 
 performance of FSTs is really important, but surely a lot can be done without 
 sacrificing that.
 (comments will hold specific ideas and problems)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4285) Improve FST API usability for mere mortals


[ 
https://issues.apache.org/jira/browse/LUCENE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470562#comment-13470562
 ] 

Michael McCandless commented on LUCENE-4285:


bq. That is bad API design; it should return an FST with nothing init.

+1, this has also bit me ... null return is bad when it's surprising, as 
clearly it is here.

Somehow we just need an FST that accepts nothing.

 Improve FST API usability for mere mortals
 --

 Key: LUCENE-4285
 URL: https://issues.apache.org/jira/browse/LUCENE-4285
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/FSTs
Reporter: David Smiley

 FST technology is something that has brought amazing advances to Lucene, yet 
 the API is hard to use for the vast majority of users like me.  I know that 
 performance of FSTs is really important, but surely a lot can be done without 
 sacrificing that.
 (comments will hold specific ideas and problems)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4285) Improve FST API usability for mere mortals

2012-10-05 Thread Dawid Weiss (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470584#comment-13470584
 ] 

Dawid Weiss commented on LUCENE-4285:
-

This is typically (?) done by making the root state follow an epsilon 
transition. If it points to a final state it means the automaton is empty and 
accepts epsilon (in other words, nothing).

But then it also adds overhead for every iteration which needs to skip over 
this epsilon transition...

 Improve FST API usability for mere mortals
 --

 Key: LUCENE-4285
 URL: https://issues.apache.org/jira/browse/LUCENE-4285
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/FSTs
Reporter: David Smiley

 FST technology is something that has brought amazing advances to Lucene, yet 
 the API is hard to use for the vast majority of users like me.  I know that 
 performance of FSTs is really important, but surely a lot can be done without 
 sacrificing that.
 (comments will hold specific ideas and problems)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4285) Improve FST API usability for mere mortals


[ 
https://issues.apache.org/jira/browse/LUCENE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470588#comment-13470588
 ] 

Robert Muir commented on LUCENE-4285:
-

If the problem with null is that the documentation isn't loud enough, we can 
make it bold?

If the problem is people dont read build()'s javadocs and we think thats bad, 
another idea is to just
throw a checked exception: then there is no sneaky bugs caused by the change 
(unlike returning EMPTY, which
could easily introduce these).


 Improve FST API usability for mere mortals
 --

 Key: LUCENE-4285
 URL: https://issues.apache.org/jira/browse/LUCENE-4285
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/FSTs
Reporter: David Smiley

 FST technology is something that has brought amazing advances to Lucene, yet 
 the API is hard to use for the vast majority of users like me.  I know that 
 performance of FSTs is really important, but surely a lot can be done without 
 sacrificing that.
 (comments will hold specific ideas and problems)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4285) Improve FST API usability for mere mortals


[ 
https://issues.apache.org/jira/browse/LUCENE-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470595#comment-13470595
 ] 

Robert Muir commented on LUCENE-4285:
-

(I hate checked exceptions and think this would only be annoying for most users
 who will just let their IDE fill in a crappy try/catch with a 
System.out.println, but
 I'm just looking out for our own code here :)


 Improve FST API usability for mere mortals
 --

 Key: LUCENE-4285
 URL: https://issues.apache.org/jira/browse/LUCENE-4285
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/FSTs
Reporter: David Smiley

 FST technology is something that has brought amazing advances to Lucene, yet 
 the API is hard to use for the vast majority of users like me.  I know that 
 performance of FSTs is really important, but surely a lot can be done without 
 sacrificing that.
 (comments will hold specific ideas and problems)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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

Build failed in Jenkins: lucene40-beaster #2079

See http://sierranevada.servebeer.com/job/lucene40-beaster/2079/

--
Started by timer
Building in workspace 
http://sierranevada.servebeer.com/job/lucene40-beaster/ws/
Cleaning up http://sierranevada.servebeer.com/job/lucene40-beaster/ws/.
Updating 
https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_0/lucene
At revision 1394778
no change for 
https://svn.apache.org/repos/asf/lucene/dev/branches/lucene_solr_4_0/lucene 
since the previous build
[lucene40-beaster] $ ant -DJAVA7_HOME=/usr/local/jdk1.7.0_01 
-DJAVA6_HOME=/usr/local/jdk1.6.0_27 -Dtests.class=org.apache.lucene.index.* 
test-core
Buildfile: http://sierranevada.servebeer.com/job/lucene40-beaster/ws/build.xml

test-core:

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ ::
[ivy:configure] :: loading settings :: file = 
http://sierranevada.servebeer.com/job/lucene40-beaster/ws/ivy-settings.xml

resolve:

init:

-clover.disable:

-clover.setup:

clover:

compile-core:

compile-test-framework:

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
http://sierranevada.servebeer.com/job/lucene40-beaster/ws/ivy-settings.xml

resolve:

BUILD FAILED
http://sierranevada.servebeer.com/job/lucene40-beaster/ws/build.xml:49: The 
following error occurred while executing this line:
http://sierranevada.servebeer.com/job/lucene40-beaster/ws/common-build.xml:643:
 The following error occurred while executing this line:
http://sierranevada.servebeer.com/job/lucene40-beaster/ws/common-build.xml:292:
 impossible to ivy retrieve: java.lang.RuntimeException: problem during 
retrieve of org.apache.lucene#core-test-framework: java.text.ParseException: 
failed to parse report: 
/home/rmuir/.ivy2/cache/org.apache.lucene-core-test-framework-default.xml: 
Premature end of file.
at 
org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:206)
at org.apache.ivy.Ivy.retrieve(Ivy.java:540)
at org.apache.ivy.ant.IvyRetrieve.doExecute(IvyRetrieve.java:67)
at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at 
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at 
org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
at org.apache.tools.ant.Task.perform(Task.java:348)
at org.apache.tools.ant.Target.execute(Target.java:390)
at org.apache.tools.ant.Target.performTasks(Target.java:411)
at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399)
at org.apache.tools.ant.Project.executeTarget(Project.java:1368)
at 
org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41)
at org.apache.tools.ant.Project.executeTargets(Project.java:1251)
at org.apache.tools.ant.Main.runBuild(Main.java:809)

Jenkins build is back to normal : lucene40-beaster #2080

See http://sierranevada.servebeer.com/job/lucene40-beaster/2080/


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

Re: Build failed in Jenkins: lucene40-beaster #2079

On Fri, Oct 5, 2012 at 4:08 PM,  hudsonsevilt...@gmail.com wrote:
 BUILD FAILED
 http://sierranevada.servebeer.com/job/lucene40-beaster/ws/build.xml:49: The 
 following error occurred while executing this line:
 http://sierranevada.servebeer.com/job/lucene40-beaster/ws/common-build.xml:643:
  The following error occurred while executing this line:
 http://sierranevada.servebeer.com/job/lucene40-beaster/ws/common-build.xml:292:
  impossible to ivy retrieve: java.lang.RuntimeException: problem during 
 retrieve of org.apache.lucene#core-test-framework: java.text.ParseException: 
 failed to parse report: 
 /home/rmuir/.ivy2/cache/org.apache.lucene-core-test-framework-default.xml: 
 Premature end of file.
 at 
 org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:206)

I've seen this a few times before, this is some bug in ivy (or the
cache needs a different locking setup or something i dont understand).

This probably happened because I'm also running 'ant test
-Dtestcase= -Dtestmethod=' in a shellscript in a loop 1000
times separately in another checkout on this machine.

-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Updated] (SOLR-3916) fl parsing is sensitive to newlines at the end of field names


 [ 
https://issues.apache.org/jira/browse/SOLR-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man updated SOLR-3916:
---

Attachment: SOLR-3916.patch

blaming this on xml parsing doesn't really seem productive, espeicially since 
you can trivially reproduce the problem from a remote client (or even with the 
solr admin UI) if you accidentally cut/paste tab characters or newlines mixed 
in your list of fields.

The fix is trivial: in some places the fl parser was naivly only checking 
character equality with ' ' instead of using Character.isWhitespace().  

patch with tests attached, running all tests and precommit on my computer now 
for further vetting.

 fl parsing is sensitive to newlines at the end of field names
 -

 Key: SOLR-3916
 URL: https://issues.apache.org/jira/browse/SOLR-3916
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0-BETA
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.0

 Attachments: SOLR-3916.patch


 As reported by giovanni.bricconi on the user list, there is a bug in fl 
 parsing that causes solr to get confused when a field name is followed by a 
 newline character -- eg: in a requestHandler default like...
 {noformat}
 !-- newlines showing using $ --$
 str name=fl$
sku,store_slug$  
 /str$
 {noformat}
 ...this results in solr assuming it should use function parsing to evaluate 
 the field name, which can cause missleading errors if the field name can't be 
 used in a function (eg: can not use FieldCache on multivalued field: 
 store_slug)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: Build failed in Jenkins: lucene40-beaster #2079

2012-10-05 Thread Dawid Weiss

This looks like an ivy bug to me -- seems to be overwriting the same
cache file so one of the parsers fails.

Dawid

On Fri, Oct 5, 2012 at 10:14 PM, Robert Muir rcm...@gmail.com wrote:
 On Fri, Oct 5, 2012 at 4:08 PM,  hudsonsevilt...@gmail.com wrote:
 BUILD FAILED
 http://sierranevada.servebeer.com/job/lucene40-beaster/ws/build.xml:49: 
 The following error occurred while executing this line:
 http://sierranevada.servebeer.com/job/lucene40-beaster/ws/common-build.xml:643:
  The following error occurred while executing this line:
 http://sierranevada.servebeer.com/job/lucene40-beaster/ws/common-build.xml:292:
  impossible to ivy retrieve: java.lang.RuntimeException: problem during 
 retrieve of org.apache.lucene#core-test-framework: java.text.ParseException: 
 failed to parse report: 
 /home/rmuir/.ivy2/cache/org.apache.lucene-core-test-framework-default.xml: 
 Premature end of file.
 at 
 org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:206)

 I've seen this a few times before, this is some bug in ivy (or the
 cache needs a different locking setup or something i dont understand).

 This probably happened because I'm also running 'ant test
 -Dtestcase= -Dtestmethod=' in a shellscript in a loop 1000
 times separately in another checkout on this machine.

 -
 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: Build failed in Jenkins: lucene40-beaster #2079

Well it looks like a configuration bug:

Ivy supports locking for this:
http://ant.apache.org/ivy/history/latest-milestone/settings/lock-strategies.html

But the default is no-lock
http://ant.apache.org/ivy/history/latest-milestone/settings/caches.html

I think we should investigate fixing lucene/ivy-settings.xml to use
locking? failures like this are annoying

On Fri, Oct 5, 2012 at 4:17 PM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
 This looks like an ivy bug to me -- seems to be overwriting the same
 cache file so one of the parsers fails.

 Dawid

 On Fri, Oct 5, 2012 at 10:14 PM, Robert Muir rcm...@gmail.com wrote:
 On Fri, Oct 5, 2012 at 4:08 PM,  hudsonsevilt...@gmail.com wrote:
 BUILD FAILED
 http://sierranevada.servebeer.com/job/lucene40-beaster/ws/build.xml:49: 
 The following error occurred while executing this line:
 http://sierranevada.servebeer.com/job/lucene40-beaster/ws/common-build.xml:643:
  The following error occurred while executing this line:
 http://sierranevada.servebeer.com/job/lucene40-beaster/ws/common-build.xml:292:
  impossible to ivy retrieve: java.lang.RuntimeException: problem during 
 retrieve of org.apache.lucene#core-test-framework: 
 java.text.ParseException: failed to parse report: 
 /home/rmuir/.ivy2/cache/org.apache.lucene-core-test-framework-default.xml: 
 Premature end of file.
 at 
 org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:206)

 I've seen this a few times before, this is some bug in ivy (or the
 cache needs a different locking setup or something i dont understand).

 This probably happened because I'm also running 'ant test
 -Dtestcase= -Dtestmethod=' in a shellscript in a loop 1000
 times separately in another checkout on this machine.

 -
 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

Re: Build failed in Jenkins: lucene40-beaster #2079

Here's my idea, i have no way to tell if its working besides running a
lot of shellscripts running 'ant test' in loops at the same time :)

Index: lucene/ivy-settings.xml
===
--- lucene/ivy-settings.xml (revision 1394624)
+++ lucene/ivy-settings.xml (working copy)
@@ -26,6 +26,8 @@
   include url=${ivy.default.settings.dir}/ivysettings-local.xml/
   include url=${ivy.default.settings.dir}/ivysettings-main-chain.xml/

+  caches lockStrategy=artifact-lock/
+
   resolvers
 ibiblio name=sonatype-releases
root=http://oss.sonatype.org/content/repositories/releases;
m2compatible=true /



On Fri, Oct 5, 2012 at 4:31 PM, Robert Muir rcm...@gmail.com wrote:
 Well it looks like a configuration bug:

 Ivy supports locking for this:
 http://ant.apache.org/ivy/history/latest-milestone/settings/lock-strategies.html

 But the default is no-lock
 http://ant.apache.org/ivy/history/latest-milestone/settings/caches.html

 I think we should investigate fixing lucene/ivy-settings.xml to use
 locking? failures like this are annoying

 On Fri, Oct 5, 2012 at 4:17 PM, Dawid Weiss
 dawid.we...@cs.put.poznan.pl wrote:
 This looks like an ivy bug to me -- seems to be overwriting the same
 cache file so one of the parsers fails.

 Dawid

 On Fri, Oct 5, 2012 at 10:14 PM, Robert Muir rcm...@gmail.com wrote:
 On Fri, Oct 5, 2012 at 4:08 PM,  hudsonsevilt...@gmail.com wrote:
 BUILD FAILED
 http://sierranevada.servebeer.com/job/lucene40-beaster/ws/build.xml:49: 
 The following error occurred while executing this line:
 http://sierranevada.servebeer.com/job/lucene40-beaster/ws/common-build.xml:643:
  The following error occurred while executing this line:
 http://sierranevada.servebeer.com/job/lucene40-beaster/ws/common-build.xml:292:
  impossible to ivy retrieve: java.lang.RuntimeException: problem during 
 retrieve of org.apache.lucene#core-test-framework: 
 java.text.ParseException: failed to parse report: 
 /home/rmuir/.ivy2/cache/org.apache.lucene-core-test-framework-default.xml: 
 Premature end of file.
 at 
 org.apache.ivy.core.retrieve.RetrieveEngine.retrieve(RetrieveEngine.java:206)

 I've seen this a few times before, this is some bug in ivy (or the
 cache needs a different locking setup or something i dont understand).

 This probably happened because I'm also running 'ant test
 -Dtestcase= -Dtestmethod=' in a shellscript in a loop 1000
 times separately in another checkout on this machine.

 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org


 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org


-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org

[jira] [Commented] (SOLR-3916) fl parsing is sensitive to newlines at the end of field names

2012-10-05 Thread Yonik Seeley (JIRA)


[ 
https://issues.apache.org/jira/browse/SOLR-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470652#comment-13470652
 ] 

Yonik Seeley commented on SOLR-3916:


bq. blaming this on xml parsing doesn't really seem productive

?

I'm suggesting this could be a much wider problem than just fl, which would 
seem to be a very productive line of conversation.

In the context of grabbing defaults from XML, we should consider trimming 
whitespace in the process of generating those defaults (rather than later).
The only downside is if certain parameters could reasonably expect to want 
leading/trailing whitespace.  If we want to support that, we could introduce a 
new type called verbatim or something.

 fl parsing is sensitive to newlines at the end of field names
 -

 Key: SOLR-3916
 URL: https://issues.apache.org/jira/browse/SOLR-3916
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0-BETA
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.0

 Attachments: SOLR-3916.patch


 As reported by giovanni.bricconi on the user list, there is a bug in fl 
 parsing that causes solr to get confused when a field name is followed by a 
 newline character -- eg: in a requestHandler default like...
 {noformat}
 !-- newlines showing using $ --$
 str name=fl$
sku,store_slug$  
 /str$
 {noformat}
 ...this results in solr assuming it should use function parsing to evaluate 
 the field name, which can cause missleading errors if the field name can't be 
 used in a function (eg: can not use FieldCache on multivalued field: 
 store_slug)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (LUCENE-4463) add support for running the same test method many times

Robert Muir created LUCENE-4463:
---

 Summary: add support for running the same test method many times
 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir


I have a shell script for this, mike has a python script, its annoying :)

I want to do something like this:

ant beast -Dtestcase= -Dtestmethod= -Diterations=100

I would be happy with a simple loop that just invokes 'test' somehow: getting a 
fresh new JVM to each iteration is desirable anyway (so you get fresh codecs, 
etc). 

the -Dtests.iters is not really useful for this because it does not allow 
-Dtestmethod and it does not give a fresh jvm.

bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times


[ 
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470672#comment-13470672
 ] 

Uwe Schindler commented on LUCENE-4463:
---

As discussed in GTalk, we can do this with a simple groovy script again. I will 
think about it, should be 6 lines of code.

 add support for running the same test method many times
 ---

 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir

 I have a shell script for this, mike has a python script, its annoying :)
 I want to do something like this:
 ant beast -Dtestcase= -Dtestmethod= -Diterations=100
 I would be happy with a simple loop that just invokes 'test' somehow: getting 
 a fresh new JVM to each iteration is desirable anyway (so you get fresh 
 codecs, etc). 
 the -Dtests.iters is not really useful for this because it does not allow 
 -Dtestmethod and it does not give a fresh jvm.
 bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times


[ 
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470678#comment-13470678
 ] 

Robert Muir commented on LUCENE-4463:
-

Here is my current script, just so you see:

{noformat}
#!/bin/bash
 /home/rmuir/log.txt
x=0
while [ $x -lt 1000 ]
do
  echo test iteration number $x
  ant test -Dtestcase=TestFoo -Dtests.method=testBar  /home/rmuir/log.txt 
21 
  x=$(( $x + 1 ))
done
{noformat}

I edit this every time i need to use it and then just use 'grep -i failed 
log.txt' to look for failures.
one problem is it fires up ant, calls resolve,compile,compile-tests all this 
stuff each time. this makes it really slow.
so if it could work from ant directly i think it would be much more efficient.

 add support for running the same test method many times
 ---

 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir

 I have a shell script for this, mike has a python script, its annoying :)
 I want to do something like this:
 ant beast -Dtestcase= -Dtestmethod= -Diterations=100
 I would be happy with a simple loop that just invokes 'test' somehow: getting 
 a fresh new JVM to each iteration is desirable anyway (so you get fresh 
 codecs, etc). 
 the -Dtests.iters is not really useful for this because it does not allow 
 -Dtestmethod and it does not give a fresh jvm.
 bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times

2012-10-05 Thread Dawid Weiss (JIRA)


[ 
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470681#comment-13470681
 ] 

Dawid Weiss commented on LUCENE-4463:
-

you can do:

ant test -Dtests.dups=100 -Dtestcase= -Dtestmethod=

It will respin the suite/test 100 times. The global starting seed will be 
identical for each suite though (because they have exactly the same name). If 
you want different seeds each time there is no way to do this other than 
re-running the task (junit4) 100 times using a script or something.

 add support for running the same test method many times
 ---

 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir

 I have a shell script for this, mike has a python script, its annoying :)
 I want to do something like this:
 ant beast -Dtestcase= -Dtestmethod= -Diterations=100
 I would be happy with a simple loop that just invokes 'test' somehow: getting 
 a fresh new JVM to each iteration is desirable anyway (so you get fresh 
 codecs, etc). 
 the -Dtests.iters is not really useful for this because it does not allow 
 -Dtestmethod and it does not give a fresh jvm.
 bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times

[
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470690#comment-13470690
]

Robert Muir commented on LUCENE-4463:
-

There are two use cases:
1. you have a seed: CAFE:DEADBEEF from the reproduce-with but it doesnt
reproduce well. so you want to run that method like 1000 times.
2. you want a new seed each time, because you sense there might be bugs out
there that you don't yet know about.

I think in this case i had #2 in mind, but maybe this test.dups works for #1? I
havent tried this yet.

add support for running the same test method many times
---

Key: LUCENE-4463
URL: https://issues.apache.org/jira/browse/LUCENE-4463
Project: Lucene - Core
Issue Type: Wish
Components: general/build
Reporter: Robert Muir

I have a shell script for this, mike has a python script, its annoying :)
I want to do something like this:
ant beast -Dtestcase= -Dtestmethod= -Diterations=100
I would be happy with a simple loop that just invokes 'test' somehow: getting
a fresh new JVM to each iteration is desirable anyway (so you get fresh
codecs, etc).
the -Dtests.iters is not really useful for this because it does not allow
-Dtestmethod and it does not give a fresh jvm.
bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times


[ 
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470694#comment-13470694
 ] 

Hoss Man commented on LUCENE-4463:
--

Just to be clear...

bq. the -Dtests.iters is not really useful for this because it does not allow 
-Dtestmethod and it does not give a fresh jvm.

-Dtests.iters definitely works with -Dtestmethod.

from test-help...

{noformat}
 [echo] # Repeats a given test N times (note the filters - individual test
 [echo] # repetitions are given suffixes, ie: testFoo[0], testFoo[1], etc...
 [echo] # so using testmethod or tests.method ending in a glob is necessary
 [echo] # to ensure iterations are run).
 [echo] ant test -Dtests.iters=N -Dtestcase=ClassName -Dtestmethod=mytest
 [echo] ant test -Dtests.iters=N -Dtestcase=ClassName -Dtests.method=mytest*
 [echo] 
 [echo] # Repeats N times but skips any tests after the first failure or M
 [echo] # initial failures.
 [echo] ant test -Dtests.iters=N -Dtests.failfast=yes -Dtestcase=...
 [echo] ant test -Dtests.iters=N -Dtests.maxfailures=M -Dtestcase=...
{noformat}

 add support for running the same test method many times
 ---

 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir

 I have a shell script for this, mike has a python script, its annoying :)
 I want to do something like this:
 ant beast -Dtestcase= -Dtestmethod= -Diterations=100
 I would be happy with a simple loop that just invokes 'test' somehow: getting 
 a fresh new JVM to each iteration is desirable anyway (so you get fresh 
 codecs, etc). 
 the -Dtests.iters is not really useful for this because it does not allow 
 -Dtestmethod and it does not give a fresh jvm.
 bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4226) Efficient compression of small to medium stored fields


[ 
https://issues.apache.org/jira/browse/LUCENE-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470699#comment-13470699
 ] 

Adrien Grand commented on LUCENE-4226:
--

Thanks, Simon!

 Efficient compression of small to medium stored fields
 --

 Key: LUCENE-4226
 URL: https://issues.apache.org/jira/browse/LUCENE-4226
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/index
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Trivial
 Fix For: 4.1, 5.0

 Attachments: CompressionBenchmark.java, CompressionBenchmark.java, 
 LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch, 
 LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch, 
 SnappyCompressionAlgorithm.java


 I've been doing some experiments with stored fields lately. It is very common 
 for an index with stored fields enabled to have most of its space used by the 
 .fdt index file. To prevent this .fdt file from growing too much, one option 
 is to compress stored fields. Although compression works rather well for 
 large fields, this is not the case for small fields and the compression ratio 
 can be very close to 100%, even with efficient compression algorithms.
 In order to improve the compression ratio for small fields, I've written a 
 {{StoredFieldsFormat}} that compresses several documents in a single chunk of 
 data. To see how it behaves in terms of document deserialization speed and 
 compression ratio, I've run several tests with different index compression 
 strategies on 100,000 docs from Mike's 1K Wikipedia articles (title and text 
 were indexed and stored):
  - no compression,
  - docs compressed with deflate (compression level = 1),
  - docs compressed with deflate (compression level = 9),
  - docs compressed with Snappy,
  - using the compressing {{StoredFieldsFormat}} with deflate (level = 1) and 
 chunks of 6 docs,
  - using the compressing {{StoredFieldsFormat}} with deflate (level = 9) and 
 chunks of 6 docs,
  - using the compressing {{StoredFieldsFormat}} with Snappy and chunks of 6 
 docs.
 For those who don't know Snappy, it is compression algorithm from Google 
 which has very high compression ratios, but compresses and decompresses data 
 very quickly.
 {noformat}
 Format   Compression ratio IndexReader.document time
 
 uncompressed 100%  100%
 doc/deflate 1 59%  616%
 doc/deflate 9 58%  595%
 doc/snappy80%  129%
 index/deflate 1   49%  966%
 index/deflate 9   46%  938%
 index/snappy  65%  264%
 {noformat}
 (doc = doc-level compression, index = index-level compression)
 I find it interesting because it allows to trade speed for space (with 
 deflate, the .fdt file shrinks by a factor of 2, much better than with 
 doc-level compression). One other interesting thing is that {{index/snappy}} 
 is almost as compact as {{doc/deflate}} while it is more than 2x faster at 
 retrieving documents from disk.
 These tests have been done on a hot OS cache, which is the worst case for 
 compressed fields (one can expect better results for formats that have a high 
 compression ratio since they probably require fewer read/write operations 
 from disk).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3916) fl parsing is sensitive to newlines at the end of field names


[ 
https://issues.apache.org/jira/browse/SOLR-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470703#comment-13470703
 ] 

Hoss Man commented on SOLR-3916:


bq. In the context of grabbing defaults from XML, we should consider trimming 
whitespace in the process of generating those defaults (rather than later).

...which can be pursued in another issue if you wish to do so.

as i've already said: this current bug is _not_ specific to getting defaults 
from the xml file, nor is it specific to leading/trailing whitespace that could 
be easily trimmed in a generic way.  Having a tab or newline or any whitespace 
character other then a simple ' ' between the names of fields in an fl string 
causes this annoying little bug -- regardless of whether it comes from xml 
config, or a remote client.

If you look at the patch, you can see my point quite easily: when parsing the 
fl, ReturnFields is naively only treating the ' ' character as whitespace and 
not recognizing any other whitespace characters that might exist between field 
names.

 fl parsing is sensitive to newlines at the end of field names
 -

 Key: SOLR-3916
 URL: https://issues.apache.org/jira/browse/SOLR-3916
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0-BETA
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.0

 Attachments: SOLR-3916.patch


 As reported by giovanni.bricconi on the user list, there is a bug in fl 
 parsing that causes solr to get confused when a field name is followed by a 
 newline character -- eg: in a requestHandler default like...
 {noformat}
 !-- newlines showing using $ --$
 str name=fl$
sku,store_slug$  
 /str$
 {noformat}
 ...this results in solr assuming it should use function parsing to evaluate 
 the field name, which can cause missleading errors if the field name can't be 
 used in a function (eg: can not use FieldCache on multivalued field: 
 store_slug)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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] (LUCENE-4464) Intersects spatial query returns polygons it shouldn't

2012-10-05 Thread solr-user (JIRA)

solr-user created LUCENE-4464:
-

 Summary: Intersects spatial query returns polygons it shouldn't
 Key: LUCENE-4464
 URL: https://issues.apache.org/jira/browse/LUCENE-4464
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/spatial
Affects Versions: 3.6.1
 Environment: linux and windows
Reporter: solr-user
Priority: Critical


full description, including sample schema and data, can be found at 
http://lucene.472066.n3.nabble.com/quot-Intersects-quot-spatial-query-returns-polygons-it-shouldn-t-td4008646.html

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times


[ 
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470725#comment-13470725
 ] 

Robert Muir commented on LUCENE-4463:
-

Just to be clear...

It really doesnt.

I'll take the (hard to reproduce seed) from 
http://sierranevada.servebeer.com/job/lucene40-beaster/1327/consoleText, and 
add -Dtests.iters=100 to it:

{noformat}
BUILD FAILED
/home/rmuir/workspace/lucene_solr_4_0/lucene/build.xml:49: The following error 
occurred while executing this line:
/home/rmuir/workspace/lucene_solr_4_0/lucene/common-build.xml:1142: The 
following error occurred while executing this line:
/home/rmuir/workspace/lucene_solr_4_0/lucene/common-build.xml:756: You are 
attempting to use 'tests.iters' in combination with a 'tests.method' value with 
does not end in a '*' -- This combination makes no sense, because the 
'tests.method' filter will be unable to match the synthetic test names 
generated by the multiple iterations.

Total time: 2 seconds
{noformat}

 add support for running the same test method many times
 ---

 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir

 I have a shell script for this, mike has a python script, its annoying :)
 I want to do something like this:
 ant beast -Dtestcase= -Dtestmethod= -Diterations=100
 I would be happy with a simple loop that just invokes 'test' somehow: getting 
 a fresh new JVM to each iteration is desirable anyway (so you get fresh 
 codecs, etc). 
 the -Dtests.iters is not really useful for this because it does not allow 
 -Dtestmethod and it does not give a fresh jvm.
 bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times


 [ 
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-4463:
--

Attachment: LUCENE-4463.patch

Here is a trivial patch doing this (it uses a for-loop of antcall/). The 
reason why doing this is:
- The naive approach is to simple use project.executeTarget(), but on the 
second run of the same target, junit4 complains about properties set from the 
previous run.
- This approach unfortunately runs all dependencies over and over, as 
antcall/ internally creates a sub-project, inherits all properties 
currently set and then executes the target in this isolated environment. No way 
around that :(
- This patch works everywhere where you can call ant test (except top-level 
as it does not import common-build.xml.


 add support for running the same test method many times
 ---

 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir
 Attachments: LUCENE-4463.patch


 I have a shell script for this, mike has a python script, its annoying :)
 I want to do something like this:
 ant beast -Dtestcase= -Dtestmethod= -Diterations=100
 I would be happy with a simple loop that just invokes 'test' somehow: getting 
 a fresh new JVM to each iteration is desirable anyway (so you get fresh 
 codecs, etc). 
 the -Dtests.iters is not really useful for this because it does not allow 
 -Dtestmethod and it does not give a fresh jvm.
 bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3916) fl parsing is sensitive to newlines at the end of field names


 [ 
https://issues.apache.org/jira/browse/SOLR-3916?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Hoss Man resolved SOLR-3916.


   Resolution: Fixed
Fix Version/s: 5.0
   4.1

Committed revision 1394836. - trunk
Committed revision 1394843. - 4x
Committed revision 1394844. - 4.0


 fl parsing is sensitive to newlines at the end of field names
 -

 Key: SOLR-3916
 URL: https://issues.apache.org/jira/browse/SOLR-3916
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0-BETA
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.0, 4.1, 5.0

 Attachments: SOLR-3916.patch


 As reported by giovanni.bricconi on the user list, there is a bug in fl 
 parsing that causes solr to get confused when a field name is followed by a 
 newline character -- eg: in a requestHandler default like...
 {noformat}
 !-- newlines showing using $ --$
 str name=fl$
sku,store_slug$  
 /str$
 {noformat}
 ...this results in solr assuming it should use function parsing to evaluate 
 the field name, which can cause missleading errors if the field name can't be 
 used in a function (eg: can not use FieldCache on multivalued field: 
 store_slug)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times


 [ 
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-4463:
--

Attachment: LUCENE-4463.patch

 add support for running the same test method many times
 ---

 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir
 Attachments: LUCENE-4463.patch


 I have a shell script for this, mike has a python script, its annoying :)
 I want to do something like this:
 ant beast -Dtestcase= -Dtestmethod= -Diterations=100
 I would be happy with a simple loop that just invokes 'test' somehow: getting 
 a fresh new JVM to each iteration is desirable anyway (so you get fresh 
 codecs, etc). 
 the -Dtests.iters is not really useful for this because it does not allow 
 -Dtestmethod and it does not give a fresh jvm.
 bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times


 [ 
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Uwe Schindler updated LUCENE-4463:
--

Attachment: (was: LUCENE-4463.patch)

 add support for running the same test method many times
 ---

 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir
 Attachments: LUCENE-4463.patch


 I have a shell script for this, mike has a python script, its annoying :)
 I want to do something like this:
 ant beast -Dtestcase= -Dtestmethod= -Diterations=100
 I would be happy with a simple loop that just invokes 'test' somehow: getting 
 a fresh new JVM to each iteration is desirable anyway (so you get fresh 
 codecs, etc). 
 the -Dtests.iters is not really useful for this because it does not allow 
 -Dtestmethod and it does not give a fresh jvm.
 bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times


[ 
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470736#comment-13470736
 ] 

Uwe Schindler commented on LUCENE-4463:
---

bq. I'll take the (hard to reproduce seed) from 
http://sierranevada.servebeer.com/job/lucene40-beaster/1327/consoleText, and 
add -Dtests.iters=100 to it:

This is the same I get with the simple script using project.executeTarget()

 add support for running the same test method many times
 ---

 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir
 Attachments: LUCENE-4463.patch


 I have a shell script for this, mike has a python script, its annoying :)
 I want to do something like this:
 ant beast -Dtestcase= -Dtestmethod= -Diterations=100
 I would be happy with a simple loop that just invokes 'test' somehow: getting 
 a fresh new JVM to each iteration is desirable anyway (so you get fresh 
 codecs, etc). 
 the -Dtests.iters is not really useful for this because it does not allow 
 -Dtestmethod and it does not give a fresh jvm.
 bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times


[ 
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470738#comment-13470738
 ] 

Uwe Schindler commented on LUCENE-4463:
---

Oh patch seems obsolete, tests.dups is enough...

 add support for running the same test method many times
 ---

 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir
 Attachments: LUCENE-4463.patch


 I have a shell script for this, mike has a python script, its annoying :)
 I want to do something like this:
 ant beast -Dtestcase= -Dtestmethod= -Diterations=100
 I would be happy with a simple loop that just invokes 'test' somehow: getting 
 a fresh new JVM to each iteration is desirable anyway (so you get fresh 
 codecs, etc). 
 the -Dtests.iters is not really useful for this because it does not allow 
 -Dtestmethod and it does not give a fresh jvm.
 bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times


[ 
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470739#comment-13470739
 ] 

Robert Muir commented on LUCENE-4463:
-

{quote}
you can do:

ant test -Dtests.dups=100 -Dtestcase= -Dtestmethod=

It will respin the suite/test 100 times. The global starting seed will be 
identical for each suite though (because they have exactly the same name). If 
you want different seeds each time there is no way to do this other than 
re-running the task (junit4) 100 times using a script or something.
{quote}

{noformat}
test:
[junit4:junit4] JUnit4 says cześć! Master seed: 968CB4DA24E595DE
[junit4:junit4] Executing 10 suites with 4 JVMs.
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.TestDemo
[junit4:junit4] OK  0.54s J3 | TestDemo.testDemo
[junit4:junit4] Completed on J3 in 1.09s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.TestDemo
[junit4:junit4] OK  0.50s J2 | TestDemo.testDemo
[junit4:junit4] Completed on J2 in 1.05s, 1 test
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.TestDemo
[junit4:junit4] OK  0.46s J0 | TestDemo.testDemo
[junit4:junit4] Completed on J0 in 0.98s, 1 test
...
{noformat}

This is really cool and fast especially since it gets multiple threads. I wish 
there was a way to get different seeds each time: 
what do you mean when you say each suite has exactly the same name? Could there 
be an option that somehow wraps each suite
with a fake name (e.g. TestDemo-1, TestDemo-2) to trick it into getting 
different ones?
 

 add support for running the same test method many times
 ---

 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir
 Attachments: LUCENE-4463.patch


 I have a shell script for this, mike has a python script, its annoying :)
 I want to do something like this:
 ant beast -Dtestcase= -Dtestmethod= -Diterations=100
 I would be happy with a simple loop that just invokes 'test' somehow: getting 
 a fresh new JVM to each iteration is desirable anyway (so you get fresh 
 codecs, etc). 
 the -Dtests.iters is not really useful for this because it does not allow 
 -Dtestmethod and it does not give a fresh jvm.
 bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times


[ 
https://issues.apache.org/jira/browse/LUCENE-4463?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13470741#comment-13470741
 ] 

Robert Muir commented on LUCENE-4463:
-

{quote}
Oh patch seems obsolete, tests.dups is enough...
{quote}

Its not enough yet: because as Dawid says, each time you run it, it currently 
gets the same seed.

This is what i want to see if we can workaround :)

 add support for running the same test method many times
 ---

 Key: LUCENE-4463
 URL: https://issues.apache.org/jira/browse/LUCENE-4463
 Project: Lucene - Core
  Issue Type: Wish
  Components: general/build
Reporter: Robert Muir
 Attachments: LUCENE-4463.patch


 I have a shell script for this, mike has a python script, its annoying :)
 I want to do something like this:
 ant beast -Dtestcase= -Dtestmethod= -Diterations=100
 I would be happy with a simple loop that just invokes 'test' somehow: getting 
 a fresh new JVM to each iteration is desirable anyway (so you get fresh 
 codecs, etc). 
 the -Dtests.iters is not really useful for this because it does not allow 
 -Dtestmethod and it does not give a fresh jvm.
 bonus points if it can use multiple jvms at the same time though :)

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4463) add support for running the same test method many times