date:20120522

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java7-64/87/

--
[...truncated 11950 lines...]
   [junit4] Completed on J0 in 0.63s, 20 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.internal.csv.writer.CSVConfigGuesserTest
   [junit4] Completed on J0 in 0.01s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.TestCSVLoader
   [junit4] Completed on J0 in 0.97s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.StatsComponentTest
   [junit4] Completed on J0 in 3.02s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.processor.URLClassifyProcessorTest
   [junit4] Completed on J0 in 0.03s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestArbitraryIndexDir
   [junit4] Completed on J0 in 0.55s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestHungarianLightStemFilterFactory
   [junit4] Completed on J0 in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestGermanLightStemFilterFactory
   [junit4] Completed on J0 in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.FieldAnalysisRequestHandlerTest
   [junit4] Completed on J0 in 0.53s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.TestOmitPositions
   [junit4] Completed on J0 in 0.49s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestPropInjectDefaults
   [junit4] Completed on J0 in 0.45s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestGermanNormalizationFilterFactory
   [junit4] Completed on J0 in 0.00s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.similarities.TestBM25SimilarityFactory
   [junit4] Completed on J0 in 0.08s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestTrimFilterFactory
   [junit4] Completed on J0 in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.update.AutoCommitTest
   [junit4] Completed on J1 in 8.83s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.SpellCheckComponentTest
   [junit4] Completed on J1 in 4.39s, 9 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestFaceting
   [junit4] Completed on J0 in 8.60s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterFSTTest
   [junit4] Completed on J0 in 0.90s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.PeerSyncTest
   [junit4] Completed on J1 in 3.07s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestJmxIntegration
   [junit4] IGNORED 0.00s J0 | TestJmxIntegration.testJmxOnCoreReload
   [junit4] Cause: Annotated @Ignore(timing problem? 
https://issues.apache.org/jira/browse/SOLR-2715)
   [junit4] Completed on J0 in 1.43s, 3 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.BasicFunctionalityTest
   [junit4] IGNORED 0.00s J1 | BasicFunctionalityTest.testDeepPaging
   [junit4] Cause: Annotated @Ignore(See SOLR-1726)
   [junit4] Completed on J1 in 1.76s, 23 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestWriterPerf
   [junit4] Completed on J1 in 0.81s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestCoreContainer
   [junit4] Completed on J0 in 1.95s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.CSVRequestHandlerTest
   [junit4] Completed on J0 in 0.53s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.highlight.HighlighterTest
   [junit4] Completed on J1 in 1.34s, 27 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.update.processor.UniqFieldsUpdateProcessorFactoryTest
   [junit4] Completed on J0 in 0.56s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.update.DocumentBuilderTest
   [junit4] Completed on J1 in 0.56s, 11 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.function.distance.DistanceFunctionTest
   [junit4] Completed on J0 in 0.66s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.SpatialFilterTest
   [junit4] Completed on J1 in 1.12s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.servlet.CacheHeaderTest
   [junit4] Completed on J0 in 0.71s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.CurrencyFieldTest
   [junit4] IGNORED 0.00s J1 | CurrencyFieldTest.testPerformance
   [junit4] Cause: Annotated @Ignore()
   [junit4] Completed on J1 in 0.76s, 8 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy1
   [junit4] Completed on J0 in 0.90s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.highlight.FastVectorHighlighterTest
   [junit4] Completed on J1 in 0.65s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestDocSet
   [junit4] Completed on J0 in 0.61s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestQueryUtils
   [junit4] Completed on J0 in 0.69s, 1 test
   [junit4]  
   [junit4] Suite:

[jira] [Commented] (SOLR-2694) LogUpdateProcessor not thread safe

2012-05-22 Thread Ethan Tao (JIRA)


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

Ethan Tao commented on SOLR-2694:
-

Hoss: The issue described in Solr-2804 also helps to some extend. 
We are building document indexing pipeline. The update chain we defined is 
enforced with singleton, thus the LogUpdateProcessor is shared among concurrent 
threads. We didn't realize the class is thread unsafe till now. 

We'll try the workaround to reduce its log level below INFO and see if it's 
acceptable. We'll create a new bug if necessary.
Thanks a lot.

-Ethan

 LogUpdateProcessor not thread safe
 --

 Key: SOLR-2694
 URL: https://issues.apache.org/jira/browse/SOLR-2694
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 1.4.1, 3.1, 3.2, 3.3, 4.0
Reporter: Jan Høydahl

 Using the LogUpdateProcessor while feeding in multiple parallell threads does 
 not work, as LogUpdateProcessor is not threadsafe.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java7-64 #83

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java7-64/83/

--
[...truncated 11125 lines...]
   [junit4] Suite: org.apache.solr.analysis.TestSpanishLightStemFilterFactory
   [junit4] Completed in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestRemoteStreaming
   [junit4] Completed in 1.51s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.ConvertedLegacyTest
   [junit4] Completed in 3.61s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.LengthFilterTest
   [junit4] Completed in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestElisionFilterFactory
   [junit4] Completed in 0.02s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestIndexSearcher
   [junit4] Completed in 2.52s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest
   [junit4] Completed in 272.03s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.LeaderElectionIntegrationTest
   [junit4] Completed in 40.90s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4] Completed in 29.42s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.TestDistributedSearch
   [junit4] Completed in 35.47s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.ZkSolrClientTest
   [junit4] Completed in 18.42s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestRecovery
   [junit4] Completed in 15.94s, 9 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.TestJoin
   [junit4] Completed in 11.95s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestRangeQuery
   [junit4] Completed in 6.45s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.function.TestFunctionQuery
   [junit4] Completed in 4.92s, 14 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSort
   [junit4] Completed in 4.40s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.TestTrie
   [junit4] Completed in 1.51s, 8 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.SolrCoreTest
   [junit4] Completed in 7.97s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.servlet.SolrRequestParserTest
   [junit4] Completed in 1.20s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterTest
   [junit4] Completed in 1.75s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.SolrCmdDistributorTest
   [junit4] Completed in 2.46s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.highlight.HighlighterTest
   [junit4] Completed in 3.22s, 27 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.function.distance.DistanceFunctionTest
   [junit4] Completed in 1.38s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.XsltUpdateRequestHandlerTest
   [junit4] Completed in 1.25s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.SpatialFilterTest
   [junit4] Completed in 1.93s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.CopyFieldTest
   [junit4] Completed in 0.89s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy1
   [junit4] IGNOR/A 0.04s | TestSolrDeletionPolicy1.testCommitAge
   [junit4] Assumption #1: This test is not working on Windows (or maybe 
machines with only 2 CPUs)
   [junit4] Completed in 1.25s, 3 tests, 1 skipped
   [junit4]  
   [junit4] Suite: 
org.apache.solr.update.processor.FieldMutatingUpdateProcessorTest
   [junit4] Completed in 1.20s, 20 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.RequestHandlersTest
   [junit4] Completed in 1.17s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.XmlUpdateRequestHandlerTest
   [junit4] Completed in 1.10s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestReversedWildcardFilterFactory
   [junit4] Completed in 0.88s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.FileBasedSpellCheckerTest
   [junit4] Completed in 1.29s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.response.TestPHPSerializedResponseWriter
   [junit4] Completed in 1.07s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.IndexReaderFactoryTest
   [junit4] Completed in 0.94s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.FieldAnalysisRequestHandlerTest
   [junit4] Completed in 1.06s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestPropInjectDefaults
   [junit4] Completed in 1.04s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.MultiTermTest
   [junit4] Completed in 0.56s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestQuerySenderNoQuery
   [junit4] Completed in 1.10s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestMergePolicyConfig
   [junit4] Completed in 0.98s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.util.TestNumberUtils

Re: Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java7-64 #80

2012-05-22 Thread Simon Willnauer

I am not sure if that is serious. I am working on that test to make it
more reliable or at least reliable in a way that if it fails its
really an error otherwise I keep on hunting ghosts. This one is almost
never reproducible - which sucks big time! I will raise the lock/wait
timeout such that a fail is really a fail.

simon
On Tue, May 22, 2012 at 8:49 AM, Dawid Weiss
dawid.we...@cs.put.poznan.pl wrote:
 This does seem to be something important though:

   [junit4] ERROR   4.82s |
 TestDocumentsWriterStallControl.testAccquireReleaseRace
   [junit4]     Throwable #1: java.lang.AssertionError: control
 claims no stalled threads but waiter seems to be blocked
   [junit4]            at
 __randomizedtesting.SeedInfo.seed([9CB402821BB69236:A6C812B023565B87]:0)
   [junit4]            at org.junit.Assert.fail(Assert.java:93)
   [junit4]            at org.junit.Assert.assertTrue(Assert.java:43)
   [junit4]            at
 org.apache.lucene.index.TestDocumentsWriterStallControl.testAccquireReleaseRace(TestDocumentsWriterStallControl.java:155)
   [junit4]            at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
 Method)
   [junit4]            at
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
   [junit4]            at
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
   [junit4]            at java.lang.reflect.Method.invoke(Method.java:601)
   [junit4]            at
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
   [junit4]            at
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)

 Followed by exceptions related to closing leaked threads from an
 executor pool I think.

 Dawid

 On Tue, May 22, 2012 at 2:54 AM,  jenk...@sd-datasolutions.de wrote:
 See 
 http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java7-64/80/changes

 Changes:

 [yonik] SOLR-3469: prevent false peersync recovery by recording buffering 
 flags in tlog

 --
 [...truncated 1330 lines...]
   [junit4]
   [junit4] Suite: org.apache.lucene.search.TestTermScorer
   [junit4] Completed in 0.02s, 3 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.index.TestStressAdvance
   [junit4] Completed in 0.66s, 1 test
   [junit4]
   [junit4] Suite: org.apache.lucene.analysis.TestCachingTokenFilter
   [junit4] Completed in 0.01s, 1 test
   [junit4]
   [junit4] Suite: org.apache.lucene.search.TestNumericRangeQuery64
   [junit4] Completed in 4.84s, 34 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.index.TestAddIndexes
   [junit4] Completed in 4.17s, 20 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.index.TestSegmentTermDocs
   [junit4] Completed in 0.44s, 5 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.index.TestNorms
   [junit4] Completed in 2.38s, 3 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.search.TestSearcherManager
   [junit4] Completed in 3.32s, 6 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.search.TestPhraseQuery
   [junit4] Completed in 2.02s, 17 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.search.TestTopDocsMerge
   [junit4] Completed in 3.78s, 1 test
   [junit4]
   [junit4] Suite: org.apache.lucene.index.TestIndexWriterDelete
   [junit4] IGNOR/A 0.01s | TestIndexWriterDelete.testApplyDeletesOnFlush
   [junit4]     Assumption #1: 'nightly' test group is disabled (@Nightly)
   [junit4] Completed in 3.20s, 19 tests, 1 skipped
   [junit4]
   [junit4] Suite: org.apache.lucene.store.TestBufferedIndexInput
   [junit4] Completed in 1.13s, 4 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.index.TestIndexWriterForceMerge
   [junit4] Completed in 1.72s, 4 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.index.TestOmitNorms
   [junit4] Completed in 0.81s, 5 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.index.TestStressNRT
   [junit4] Completed in 0.20s, 1 test
   [junit4]
   [junit4] Suite: org.apache.lucene.search.spans.TestSpans
   [junit4] Completed in 0.91s, 25 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.util.TestCollectionUtil
   [junit4] Completed in 2.24s, 5 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.index.TestParallelCompositeReader
   [junit4] Completed in 0.26s, 8 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.util.automaton.TestUTF32ToUTF8
   [junit4] Completed in 0.94s, 5 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.search.TestSimpleExplanations
   [junit4] Completed in 1.22s, 69 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.index.TestSegmentReader
   [junit4] Completed in 0.76s, 6 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.util.TestDoubleBarrelLRUCache
   [junit4] Completed in 1.03s, 2 tests
   [junit4]
   [junit4] Suite: org.apache.lucene.util.TestRamUsageEstimatorOnWildAnimals
   [junit4] Completed in 0.66s, 1 test
   [junit4]
   [junit4] Suite:

[jira] [Resolved] (LUCENE-4071) DWStallControl can deadlock IW if no flushes are running / pending

2012-05-22 Thread Simon Willnauer (JIRA)


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

Simon Willnauer resolved LUCENE-4071.
-

Resolution: Fixed

committed to trunk

 DWStallControl can deadlock IW if no flushes are running / pending
 --

 Key: LUCENE-4071
 URL: https://issues.apache.org/jira/browse/LUCENE-4071
 Project: Lucene - Java
  Issue Type: Bug
  Components: core/index
Affects Versions: 4.0
Reporter: Simon Willnauer
Assignee: Simon Willnauer
Priority: Critical
 Fix For: 4.0

 Attachments: LUCENE-4071.patch, LUCENE-4071.patch


 DWStallControl currently only checks if the net bytes used by all the DWPT 
 and deletes exceeds the stall limit (2*MAX_RAM_BUFFER). This is generally a 
 very good default but in certain situations we can exceed this limit even 
 without an ongoing flush. Stalling is used to prevent IW overloading due to 
 slow flushes etc. which should not happen too often in practice. With a 
 smallish RAM Buffer and a bigger document we can easily get into the stage 
 where we stall the DW without a chance to free up the memory.  
 I think we should make sure that a pending or running flush can free up 
 enough memory to unstall.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[JENKINS] Solr-trunk - Build # 1862 - Failure

2012-05-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Solr-trunk/1862/

2 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest

Error Message:
ERROR: SolrIndexSearcher opens=80 closes=78

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=80 closes=78
at __randomizedtesting.SeedInfo.seed([D887966C63468EE7]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:185)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:82)
at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:752)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:56)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)


REGRESSION:  org.apache.solr.cloud.RecoveryZkTest.testDistribSearch

Error Message:
Thread threw an uncaught exception, thread: Thread[Lucene Merge Thread #2,6,]

Stack Trace:
java.lang.RuntimeException: Thread threw an uncaught exception, thread: 
Thread[Lucene Merge Thread #2,6,]
at 
com.carrotsearch.randomizedtesting.RunnerThreadGroup.processUncaught(RunnerThreadGroup.java:96)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:857)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:669)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:695)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:734)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:745)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:56)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at

Jenkins build is back to normal : Lucene-Solr-trunk-Linux-Java7-64 #88

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java7-64/88/changes


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

[jira] [Commented] (SOLR-3474) It would be great if the SolrCloud cluster viz views would auto refresh.


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

Stefan Matheis (steffkes) commented on SOLR-3474:
-

Mark, what would you like to see here? Only the state of {{live_nodes}}? or 
should we refresh both, {{live_nodes}} and {{clusterstate.json}}? A automatic 
refresh every 10 seconds, the same way we have it already on the logviewer?

 It would be great if the SolrCloud cluster viz views would auto refresh.
 

 Key: SOLR-3474
 URL: https://issues.apache.org/jira/browse/SOLR-3474
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Priority: Minor

 If you are sitting on that screen and knock down a server, would be nice for 
 that to show up without requiring a refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java6-64 #144

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/144/changes

Changes:

[simonw] LUCENE-4071: DWStallControl can deadlock if stalled and flushMemory 
can not release the stall state

--
[...truncated 10877 lines...]
   [junit4]   2at 
org.apache.solr.handler.SnapPuller.copyIndexFiles(SnapPuller.java:698)
   [junit4]   2at 
org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:378)
   [junit4]   2at 
org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:298)
   [junit4]   2at 
org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:176)
   [junit4]   2at 
java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441)
   [junit4]   2at 
java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317)
   [junit4]   2at 
java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150)
   [junit4]   2at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98)
   [junit4]   2at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180)
   [junit4]   2at 
java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204)
   [junit4]   2at 
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
   [junit4]   2at 
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
   [junit4]   2at java.lang.Thread.run(Thread.java:662)
   [junit4]   2 
   [junit4]   2 NOTE: reproduce with: ant test 
-Dtestcase=TestReplicationHandler -Dtests.method=test 
-Dtests.seed=4D03CE7F63ABFBA9 -Dtests.locale=sv 
-Dtests.timezone=America/St_Barthelemy -Dargs=-Dfile.encoding=Cp1252
   [junit4]   2
   [junit4] (@AfterClass output)
   [junit4]   2 NOTE: test params are: codec=Lucene40, 
sim=RandomSimilarityProvider(queryNorm=false,coord=true): {}, locale=sv, 
timezone=America/St_Barthelemy
   [junit4]   2 NOTE: Windows 7 6.1 amd64/Sun Microsystems Inc. 1.6.0_32 
(64-bit)/cpus=2,threads=1,free=93980016,total=269025280
   [junit4]   2 NOTE: All tests run in this JVM: [AutoCommitTest, 
LoggingHandlerTest, CommonGramsQueryFilterFactoryTest, NodeStateWatcherTest, 
TestQuerySenderNoQuery, TestDistributedSearch, TestLuceneMatchVersion, 
TestReversedWildcardFilterFactory, RequiredFieldsTest, 
TestNorwegianMinimalStemFilterFactory, UniqFieldsUpdateProcessorFactoryTest, 
TestHungarianLightStemFilterFactory, DistributedSpellCheckComponentTest, 
TestJmxMonitoredMap, SolrIndexConfigTest, RecoveryZkTest, 
LukeRequestHandlerTest, TimeZoneUtilsTest, SuggesterTest, DateMathParserTest, 
LeaderElectionIntegrationTest, TestEnglishMinimalStemFilterFactory, 
TestRemoveDuplicatesTokenFilterFactory, StatsComponentTest, SuggesterFSTTest, 
ZkNodePropsTest, TestDFRSimilarityFactory, TestTypeTokenFilterFactory, 
TestKeywordMarkerFilterFactory, XsltUpdateRequestHandlerTest, MultiTermTest, 
DisMaxRequestHandlerTest, TestKStemFilterFactory, TestCoreContainer, 
QueryElevationComponentTest, TestGalicianMinimalStemFilterFactory, 
TestDictionaryCompoundWordTokenFilterFactory, TestElisionFilterFactory, 
JsonLoaderTest, TestRussianLightStemFilterFactory, MBeansHandlerTest, 
FileUtilsTest, TestPatternReplaceCharFilterFactory, SolrCmdDistributorTest, 
TestRecovery, SolrInfoMBeanTest, TestDelimitedPayloadTokenFilterFactory, 
TestExtendedDismaxParser, DirectSolrConnectionTest, TestCSVResponseWriter, 
DebugComponentTest, FieldAnalysisRequestHandlerTest, PingRequestHandlerTest, 
SolrPluginUtilsTest, TestFaceting, TestUAX29URLEmailTokenizerFactory, 
FastVectorHighlighterTest, CacheHeaderTest, TestSpanishLightStemFilterFactory, 
EchoParamsTest, MinimalSchemaTest, TestQuerySenderListener, 
TestBeiderMorseFilterFactory, TestHashPartitioner, 
TestPatternReplaceFilterFactory, NumericFieldsTest, TestMultiCoreConfBootstrap, 
TestPatternTokenizerFactory, CloudStateUpdateTest, TestValueSourceCache, 
TestGreekLowerCaseFilterFactory, TestIrishLowerCaseFilterFactory, 
ZkSolrClientTest, TermVectorComponentTest, SnowballPorterFilterFactoryTest, 
TestFoldingMultitermQuery, BasicZkTest, TestCollationKeyFilterFactory, 
TestIndexingPerformance, DirectUpdateHandlerOptimizeTest, 
FullSolrCloudDistribCmdsTest, TestWordDelimiterFilterFactory, 
DistributedQueryElevationComponentTest, TestRandomFaceting, 
TestChineseTokenizerFactory, TestShingleFilterFactory, IndexReaderFactoryTest, 
TestBadConfig, TestPortugueseStemFilterFactory, DirectUpdateHandlerTest, 
DistributedTermsComponentTest, DocumentAnalysisRequestHandlerTest, 
TestGreekStemFilterFactory, TestCapitalizationFilterFactory, 
URLClassifyProcessorTest, TestPorterStemFilterFactory, SortByFunctionTest, 
TestNorwegianLightStemFilterFactory, NoCacheHeaderTest, SOLR749Test, 
JSONWriterTest, SoftAutoCommitTest,

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java7-64 #85

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java7-64/85/

--
[...truncated 10951 lines...]
   [junit4]   2 179947 T3012 oas.SolrTestCaseJ4.endTrackingSearchers SEVERE 
ERROR: SolrIndexSearcher opens=74 closes=73
   [junit4]   2 NOTE: test params are: codec=Lucene40, 
sim=RandomSimilarityProvider(queryNorm=false,coord=true): {}, locale=el_GR, 
timezone=Asia/Krasnoyarsk
   [junit4]   2 NOTE: Windows 7 6.1 amd64/Oracle Corporation 1.7.0_04 
(64-bit)/cpus=2,threads=1,free=83311680,total=287375360
   [junit4]   2 NOTE: All tests run in this JVM: [TestRemoteStreaming, 
TestDictionaryCompoundWordTokenFilterFactory, CopyFieldTest, 
PingRequestHandlerTest, ShowFileRequestHandlerTest, 
TestJapanesePartOfSpeechStopFilterFactory, SortByFunctionTest, 
TestSolrCoreProperties, SpellCheckCollatorTest, TestWikipediaTokenizerFactory, 
DistanceFunctionTest, TestQuerySenderNoQuery, 
TestNorwegianMinimalStemFilterFactory, TestFrenchMinimalStemFilterFactory, 
TestGermanMinimalStemFilterFactory, CloudStateUpdateTest, 
XmlUpdateRequestHandlerTest, StandardRequestHandlerTest, TestDistributedSearch, 
TestChineseFilterFactory, SuggesterTSTTest, TestNumberUtils, 
TestSolrQueryParser, TestJapaneseBaseFormFilterFactory, 
TestTurkishLowerCaseFilterFactory, TestOmitPositions, 
TestGermanStemFilterFactory, DistributedTermsComponentTest, 
SpellingQueryConverterTest, SolrCmdDistributorTest, TestWriterPerf, 
SolrPluginUtilsTest, TestDefaultSimilarityFactory, 
TestPortugueseLightStemFilterFactory, DocumentAnalysisRequestHandlerTest, 
SimpleFacetsTest, BasicFunctionalityTest, SOLR749Test, TestMultiWordSynonyms, 
FieldMutatingUpdateProcessorTest, TestCapitalizationFilterFactory, 
TestFrenchLightStemFilterFactory, TestNorwegianLightStemFilterFactory, 
TestSuggestSpellingConverter, TestBulgarianStemFilterFactory, 
TestIndexingPerformance, HighlighterTest, TestReversedWildcardFilterFactory, 
TestIBSimilarityFactory, OpenExchangeRatesOrgProviderTest, 
CoreAdminHandlerTest, TestRussianLightStemFilterFactory, TestJmxIntegration, 
TestPropInjectDefaults, PeerSyncTest, TestBinaryField, SuggesterTest, 
TestWordDelimiterFilterFactory, TestSort, TestTrimFilterFactory, 
IndexSchemaRuntimeFieldTest, TestSolrDeletionPolicy1, 
SolrCoreCheckLockOnStartupTest, RequestHandlersTest, DateMathParserTest, 
TestTypeTokenFilterFactory, TestLatvianStemFilterFactory, 
DirectUpdateHandlerTest, UpdateParamsTest, LegacyHTMLStripCharFilterTest, 
TestUAX29URLEmailTokenizerFactory, TestMultiCoreConfBootstrap, 
DistributedSpellCheckComponentTest, ConvertedLegacyTest, 
TestItalianLightStemFilterFactory, TestGalicianMinimalStemFilterFactory, 
TestKeepFilterFactory, ZkControllerTest, CloudStateTest, 
TestBrazilianStemFilterFactory, UpdateRequestProcessorFactoryTest, 
TestHTMLStripCharFilterFactory, PluginInfoTest, TestPerFieldSimilarity, 
QueryElevationComponentTest, UUIDFieldTest, TestPluginEnable, 
SignatureUpdateProcessorFactoryTest, TestCJKWidthFilterFactory, 
LengthFilterTest, DirectSolrSpellCheckerTest, TestDFRSimilarityFactory, 
TestSearchPerf, BasicZkTest, TestHyphenationCompoundWordTokenFilterFactory, 
CommonGramsQueryFilterFactoryTest, TestPHPSerializedResponseWriter, 
TestGalicianStemFilterFactory, TestBinaryResponseWriter, 
TestShingleFilterFactory, NodeStateWatcherTest, NoCacheHeaderTest, 
TestJapaneseTokenizerFactory, SpellPossibilityIteratorTest, 
XsltUpdateRequestHandlerTest, TestCJKBigramFilterFactory, 
TestBM25SimilarityFactory, FullSolrCloudDistribCmdsTest, 
TermVectorComponentTest, SampleTest, JsonLoaderTest, TestCSVResponseWriter, 
TestBeiderMorseFilterFactory, TestRealTimeGet, TestThaiWordFilterFactory, 
ZkSolrClientTest, RecoveryZkTest, TestSolrXMLSerializer, TestNGramFilters, 
TestPortugueseMinimalStemFilterFactory, TestBadConfig, TestConfig, 
TestPseudoReturnFields, TestKeywordMarkerFilterFactory, 
FieldAnalysisRequestHandlerTest, TimeZoneUtilsTest, 
TestCollationKeyRangeQueries, RAMDirectoryFactoryTest, TestQueryTypes, 
AutoCommitTest, MultiTermTest, TestGreekLowerCaseFilterFactory, 
TestIndonesianStemFilterFactory, TestStopFilterFactory, TestGroupingSearch, 
OutputWriterTest, SystemInfoHandlerTest, TestSlowSynonymFilter, 
DirectUpdateHandlerOptimizeTest, StatsComponentTest, CurrencyFieldTest, 
DirectSolrConnectionTest, SolrIndexConfigTest, 
TestStemmerOverrideFilterFactory, TestXIncludeConfig, TestFiltering, 
TestKStemFilterFactory, AlternateDirectoryTest, TestValueSourceCache, 
TestPatternReplaceCharFilterFactory, SuggesterFSTTest, 
NotRequiredUniqueKeyTest, TestPersianNormalizationFilterFactory, 
TestCJKTokenizerFactory, TestRandomFaceting, SpellCheckComponentTest, 
TestRemoveDuplicatesTokenFilterFactory, PolyFieldTest, TestLRUCache, 
PrimitiveFieldTypeTest, EchoParamsTest, SuggesterWFSTTest, 
TestCzechStemFilterFactory, TestHashPartitioner, TestArbitraryIndexDir, 
TestReverseStringFilterFactory, TestEnglishMinimalStemFilterFactory, 
CSVRequestHandlerTest,

Jenkins build is back to normal : Lucene-Solr-trunk-Windows-Java6-64 #145

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/145/


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

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 14258 - Failure

2012-05-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/14258/

1 tests failed.
FAILED:  junit.framework.TestSuite.org.apache.solr.cloud.BasicDistributedZkTest

Error Message:
ERROR: SolrIndexSearcher opens=79 closes=77

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=79 closes=77
at __randomizedtesting.SeedInfo.seed([64A0C2BFE2B2C5A]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:185)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:82)
at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:752)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:56)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)




Build Log (for compile errors):
[...truncated 11134 lines...]



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

[jira] [Commented] (LUCENE-4072) CharFilter that Unicode-normalizes input

2012-05-22 Thread Robert Muir (JIRA)


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

Robert Muir commented on LUCENE-4072:
-

Hello, if you are willing to contribute this under the Apache license 
(http://www.apache.org/licenses/LICENSE-2.0.html), would
you mind uploading a .zip file of your codebase (git has a button to create 
it), and check the box Grant license to ASF for inclusion in ASF works
when doing the upload? 

Then I can help turn it into a patch. Thanks again!

 CharFilter that Unicode-normalizes input
 

 Key: LUCENE-4072
 URL: https://issues.apache.org/jira/browse/LUCENE-4072
 Project: Lucene - Java
  Issue Type: New Feature
  Components: modules/analysis
Reporter: Ippei UKAI

 I'd like to contribute a CharFilter that Unicode-normalizes input with ICU4J.
 The benefit of having this process as CharFilter is that tokenizer can work 
 on normalised text while offset-correction ensuring fast vector highlighter 
 and other offset-dependent features do not break.
 The implementation is available at following repository:
 https://github.com/ippeiukai/ICUNormalizer2CharFilter
 Unfortunately this is my unpaid side-project and cannot spend much time to 
 merge my work to Lucene to make appropriate patch. I'd appreciate it if 
 anyone could give it a go. I'm happy to relicense it to whatever that meets 
 your needs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java6-64 #146

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/146/

--
[...truncated 10886 lines...]
   [junit4] ERROR   0.00s | BasicDistributedZkTest (suite)
   [junit4] Throwable #1: java.lang.AssertionError: ERROR: 
SolrIndexSearcher opens=78 closes=77
   [junit4]at 
__randomizedtesting.SeedInfo.seed([C6B7A0596B7946E3]:0)
   [junit4]at org.junit.Assert.fail(Assert.java:93)
   [junit4]at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:185)
   [junit4]at 
org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:82)
   [junit4]at sun.reflect.GeneratedMethodAccessor16.invoke(Unknown 
Source)
   [junit4]at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   [junit4]at java.lang.reflect.Method.invoke(Method.java:597)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:752)
   [junit4]at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
   [junit4]at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
   [junit4]at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
   [junit4]at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
   [junit4]at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
   [junit4]at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
   [junit4]at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
   [junit4]at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
   [junit4]at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
   [junit4]at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
   [junit4]at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:56)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)
   [junit4]
   [junit4] Completed in 187.08s, 1 test, 1 failure  FAILURES!
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4] Completed in 29.60s, 1 test
   [junit4]  
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedTermsComponentTest
   [junit4] Completed in 13.96s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.ZkControllerTest
   [junit4] Completed in 13.32s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.SpellCheckComponentTest
   [junit4] Completed in 9.94s, 9 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.PeerSyncTest
   [junit4] Completed in 5.78s, 1 test
   [junit4]  
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedQueryElevationComponentTest
   [junit4] Completed in 5.05s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterFSTTest
   [junit4] Completed in 1.73s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.TestTrie
   [junit4] Completed in 2.03s, 8 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.StatsComponentTest
   [junit4] Completed in 7.58s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.StandardRequestHandlerTest
   [junit4] Completed in 1.45s, 1 test
   [junit4]  
   [junit4] Suite: 
org.apache.solr.update.processor.SignatureUpdateProcessorFactoryTest
   [junit4] Completed in 2.06s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.CSVRequestHandlerTest
   [junit4] Completed in 1.54s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.SpellCheckCollatorTest
   [junit4] Completed in 2.29s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterTSTTest
   [junit4] Completed in 2.09s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestBinaryResponseWriter
   [junit4] Completed in 3.04s, 2 tests
   [junit4]  
   [junit4] Suite:

Jenkins build is back to normal : Lucene-Solr-trunk-Windows-Java7-64 #86

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java7-64/86/


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

[jira] [Commented] (SOLR-3474) It would be great if the SolrCloud cluster viz views would auto refresh.

2012-05-22 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-3474:
---

I think live_nodes and clusterstate.json auto update would be nice - but most 
important to me is the cluster state visualization - I guess that means we need 
to get both cluster.json and live_nodes anyway, because you need all that to 
create the cluster viz. My worry is that you put your browser on that page to 
make sure everything is happy, and oh a node goes down and everything still 
looks green an hour later - until you hit refresh...

Every 10 seconds sounds reasonable to me.

 It would be great if the SolrCloud cluster viz views would auto refresh.
 

 Key: SOLR-3474
 URL: https://issues.apache.org/jira/browse/SOLR-3474
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Priority: Minor

 If you are sitting on that screen and knock down a server, would be nice for 
 that to show up without requiring a refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3474) It would be great if the SolrCloud cluster viz views would auto refresh.


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

Stefan Matheis (steffkes) updated SOLR-3474:


  Component/s: web gui
   contrib - Solr Cell (Tika extraction)
Affects Version/s: 4.0
Fix Version/s: 4.0
 Assignee: Stefan Matheis (steffkes)

 It would be great if the SolrCloud cluster viz views would auto refresh.
 

 Key: SOLR-3474
 URL: https://issues.apache.org/jira/browse/SOLR-3474
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud, web gui
Affects Versions: 4.0
Reporter: Mark Miller
Assignee: Stefan Matheis (steffkes)
Priority: Minor
 Fix For: 4.0


 If you are sitting on that screen and knock down a server, would be nice for 
 that to show up without requiring a refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3474) It would be great if the SolrCloud cluster viz views would auto refresh.


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

Stefan Matheis (steffkes) updated SOLR-3474:


Component/s: (was: contrib - Solr Cell (Tika extraction))
 SolrCloud

 It would be great if the SolrCloud cluster viz views would auto refresh.
 

 Key: SOLR-3474
 URL: https://issues.apache.org/jira/browse/SOLR-3474
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud, web gui
Affects Versions: 4.0
Reporter: Mark Miller
Assignee: Stefan Matheis (steffkes)
Priority: Minor
 Fix For: 4.0


 If you are sitting on that screen and knock down a server, would be nice for 
 that to show up without requiring a refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3474) It would be great if the SolrCloud cluster viz views would auto refresh.


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

Stefan Matheis (steffkes) commented on SOLR-3474:
-

perhaps i should write down everything i think about the next time ;o i was 
also talking about the two Graph-Views. I'll see what we can do here, hold on :)

 It would be great if the SolrCloud cluster viz views would auto refresh.
 

 Key: SOLR-3474
 URL: https://issues.apache.org/jira/browse/SOLR-3474
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud, web gui
Affects Versions: 4.0
Reporter: Mark Miller
Assignee: Stefan Matheis (steffkes)
Priority: Minor
 Fix For: 4.0


 If you are sitting on that screen and knock down a server, would be nice for 
 that to show up without requiring a refresh.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Jenkins build is back to normal : Lucene-Solr-trunk-Windows-Java6-64 #147

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/147/


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

[jira] [Commented] (SOLR-2058) Adds optional phrase slop to edismax pf2, pf3 and pf parameters with field~slop^boost syntax

2012-05-22 Thread JIRA


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

Jan Høydahl commented on SOLR-2058:
---

I did a lot of things in the same patch - including ps2, ps3 support and 
refactoring of FieldSpec parsing to a separate class, and adding test cases for 
boosting. But there is wrapping up to do and I don't know if I'm 100% happy 
with using RegEx for parsing fieldspec. I'll attach what I have, but as I say I 
think it is better to add some of these improvements incrementally.

 Adds optional phrase slop to edismax pf2, pf3 and pf parameters with 
 field~slop^boost syntax
 

 Key: SOLR-2058
 URL: https://issues.apache.org/jira/browse/SOLR-2058
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
 Environment: n/a
Reporter: Ron Mayer
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-2058.patch, edismax_pf_with_slop_v2.1.patch, 
 edismax_pf_with_slop_v2.patch, pf2_with_slop.patch


 http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201008.mbox/%3c4c659119.2010...@0ape.com%3E
 {quote}
 From  Ron Mayer r...@0ape.com
 ... my results might  be even better if I had a couple different pf2s with 
 different ps's  at the same time.   In particular.   One with ps=0 to put a 
 high boost on ones the have  the right ordering of words.  For example 
 insuring that [the query]:
   red hat black jacket
  boosts only documents with red hats and not black hats.   And another 
 pf2 with a more modest boost with ps=5 or so to handle the query above also 
 boosting docs with 
   red baseball hat.
 {quote}
 [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201008.mbox/%3caanlktimd+v3g6d_mnhp+jykkd+dej8fvmvf_1lqoi...@mail.gmail.com%3E]
 {quote}
 From  Yonik Seeley yo...@lucidimagination.com
 Perhaps fold it into the pf/pf2 syntax?
 pf=text^2// current syntax... makes phrases with a boost of 2
 pf=text~1^2  // proposed syntax... makes phrases with a slop of 1 and
 a boost of 2
 That actually seems pretty natural given the lucene query syntax - an
 actual boosted sloppy phrase query already looks like
 {{text:foo bar~1^2}}
 -Yonik
 {quote}
 [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201008.mbox/%3calpine.deb.1.10.1008161300510.6...@radix.cryptio.net%3E]
 {quote}
 From  Chris Hostetter hossman_luc...@fucit.org
 Big +1 to this idea ... the existing ps param can stick arround as the 
 default for any field that doesn't specify it's own slop in the pf/pf2/pf3 
 fields using the ~ syntax.
 -Hoss
 {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-2058) Adds optional phrase slop to edismax pf2, pf3 and pf parameters with field~slop^boost syntax

2012-05-22 Thread JIRA


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

Jan Høydahl updated SOLR-2058:
--

Attachment: SOLR-2058-and-3351-not-finished.patch

Attaching a patch doing also some ps2/ps3 stuff, adding more tests etc, but 
it's not finished. Unfortunately it's big partly due to whitespace differences

 Adds optional phrase slop to edismax pf2, pf3 and pf parameters with 
 field~slop^boost syntax
 

 Key: SOLR-2058
 URL: https://issues.apache.org/jira/browse/SOLR-2058
 Project: Solr
  Issue Type: Improvement
  Components: query parsers
 Environment: n/a
Reporter: Ron Mayer
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-2058-and-3351-not-finished.patch, SOLR-2058.patch, 
 edismax_pf_with_slop_v2.1.patch, edismax_pf_with_slop_v2.patch, 
 pf2_with_slop.patch


 http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201008.mbox/%3c4c659119.2010...@0ape.com%3E
 {quote}
 From  Ron Mayer r...@0ape.com
 ... my results might  be even better if I had a couple different pf2s with 
 different ps's  at the same time.   In particular.   One with ps=0 to put a 
 high boost on ones the have  the right ordering of words.  For example 
 insuring that [the query]:
   red hat black jacket
  boosts only documents with red hats and not black hats.   And another 
 pf2 with a more modest boost with ps=5 or so to handle the query above also 
 boosting docs with 
   red baseball hat.
 {quote}
 [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201008.mbox/%3caanlktimd+v3g6d_mnhp+jykkd+dej8fvmvf_1lqoi...@mail.gmail.com%3E]
 {quote}
 From  Yonik Seeley yo...@lucidimagination.com
 Perhaps fold it into the pf/pf2 syntax?
 pf=text^2// current syntax... makes phrases with a boost of 2
 pf=text~1^2  // proposed syntax... makes phrases with a slop of 1 and
 a boost of 2
 That actually seems pretty natural given the lucene query syntax - an
 actual boosted sloppy phrase query already looks like
 {{text:foo bar~1^2}}
 -Yonik
 {quote}
 [http://mail-archives.apache.org/mod_mbox/lucene-solr-user/201008.mbox/%3calpine.deb.1.10.1008161300510.6...@radix.cryptio.net%3E]
 {quote}
 From  Chris Hostetter hossman_luc...@fucit.org
 Big +1 to this idea ... the existing ps param can stick arround as the 
 default for any field that doesn't specify it's own slop in the pf/pf2/pf3 
 fields using the ~ syntax.
 -Hoss
 {quote}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Created] (SOLR-3477) SOLR does not start up when no cores are defined

2012-05-22 Thread Sebastian Schaffert (JIRA)

Sebastian Schaffert created SOLR-3477:
-

 Summary: SOLR does not start up when no cores are defined
 Key: SOLR-3477
 URL: https://issues.apache.org/jira/browse/SOLR-3477
 Project: Solr
  Issue Type: Bug
  Components: search
Affects Versions: 3.6
 Environment: All environments
Reporter: Sebastian Schaffert
Priority: Critical


Since version 3.6.0, Solr does not start up when no cores are defined in 
solr.xml. The problematic code is in CoresContainer.java, lines 171-173.

org.apache.solr.common.SolrException: No cores were created, please check the 
logs for errors
at 
org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:172)
 ~[solr-core-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:38]
at 
org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:96) 
~[solr-core-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:38]
...


In our case, this is however a valid situation, because we create the cores 
programatically by calling the webservices to register new cores. The server is 
initially started with no cores defined, and depending on the configuration of 
our application, cores are then created dynamically.

For the time being, we have to stick with version 3.5, which did not have this 
problem (or feature).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java6-64 #149

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/149/changes

Changes:

[rmuir] preflex codec still depends on field name interning, so test it some

--
[...truncated 10786 lines...]
   [junit4] Completed in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: 
org.apache.solr.analysis.TestJapanesePartOfSpeechStopFilterFactory
   [junit4] Completed in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestQueryUtils
   [junit4] Completed in 1.76s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.TestPluginEnable
   [junit4] Completed in 0.22s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.JsonLoaderTest
   [junit4] Completed in 1.61s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.TestJoin
   [junit4] Completed in 12.38s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestStopFilterFactory
   [junit4] Completed in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.FullSolrCloudDistribCmdsTest
   [junit4] Completed in 42.68s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.NodeStateWatcherTest
   [junit4] Completed in 22.77s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.BasicDistributedZkTest
   [junit4] Completed in 61.04s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.ZkSolrClientTest
   [junit4] Completed in 16.42s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestPhoneticFilterFactory
   [junit4] Completed in 10.74s, 5 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedSpellCheckComponentTest
   [junit4] Completed in 19.76s, 1 test
   [junit4]  
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedTermsComponentTest
   [junit4] Completed in 24.35s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.BasicZkTest
   [junit4] Completed in 11.72s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestFaceting
   [junit4] Completed in 18.95s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestRangeQuery
   [junit4] Completed in 4.75s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.PeerSyncTest
   [junit4] Completed in 5.55s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.ConvertedLegacyTest
   [junit4] Completed in 3.15s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSurroundQueryParser
   [junit4] Completed in 0.82s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.admin.CoreAdminHandlerTest
   [junit4] Completed in 1.82s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.SpellCheckCollatorTest
   [junit4] Completed in 1.42s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.servlet.CacheHeaderTest
   [junit4] Completed in 0.98s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.SolrIndexConfigTest
   [junit4] Completed in 1.68s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestDocSet
   [junit4] Completed in 0.66s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.XmlUpdateRequestHandlerTest
   [junit4] Completed in 1.17s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.TestCSVLoader
   [junit4] Completed in 1.52s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.DebugComponentTest
   [junit4] Completed in 1.20s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.PrimitiveFieldTypeTest
   [junit4] Completed in 1.26s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.response.TestPHPSerializedResponseWriter
   [junit4] Completed in 0.94s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.RequiredFieldsTest
   [junit4] Completed in 0.82s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.DirectUpdateHandlerOptimizeTest
   [junit4] Completed in 1.24s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.highlight.HighlighterConfigTest
   [junit4] Completed in 1.18s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestArbitraryIndexDir
   [junit4] Completed in 1.05s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.request.JSONWriterTest
   [junit4] Completed in 1.13s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.QueryParsingTest
   [junit4] Completed in 1.07s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.AlternateDirectoryTest
   [junit4] Completed in 1.55s, 1 test
   [junit4]  
   [junit4] Suite: 
org.apache.solr.update.processor.UpdateRequestProcessorFactoryTest
   [junit4] Completed in 1.28s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestMergePolicyConfig
   [junit4] Completed in 1.18s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.UUIDFieldTest
   [junit4] Completed in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.util.TestNumberUtils
   [junit4] Completed in 0.32s, 1 test

[jira] [Updated] (SOLR-3476) Create a Solr Core with a given commit point

2012-05-22 Thread ludovic Boutros (JIRA)

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

ludovic Boutros updated SOLR-3476:
--

Attachment: commitPoint.patch

This patch adds this functionality:

The STATUS command in the CoreAdminHandler gives now the generation of a core
and the generation list available in the index currently.
The core creation has now an additional parameter (optional):
commitPointGeneration.
It is the generation of the wanted commit point.

I will add some more examples tomorrow.

If someone could check that everything is ok with this patch that would be
great !

Create a Solr Core with a given commit point

Key: SOLR-3476
URL: https://issues.apache.org/jira/browse/SOLR-3476
Project: Solr
Issue Type: New Feature
Components: multicore
Affects Versions: 3.6
Reporter: ludovic Boutros
Attachments: commitPoint.patch

In some configurations, we need to open new cores with a given commit point.
For instance, when the publication of new documents must be controlled (legal
obligations) in a master-slave configuration there are two cores on the same
instanceDir and dataDir which are using two versions of the index.
The switch of the two cores is done manually.
The problem is that when the replication is done one day before the switch,
if any problem occurs, and we need to restart tomcat, the new documents are
published.
With this functionality, we could ensure that the index generation used by
the core used for querying is always the good one.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira

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

[jira] [Commented] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor

2012-05-22 Thread Tommaso Teofili (JIRA)


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

Tommaso Teofili commented on SOLR-3425:
---

Mark, I'd commit this quick fix for now so that we solve the bug and maybe we 
can start discussing about a new collection management API on a different issue.

 CloudSolrServer can't create cores when using the zkHost based constructor
 --

 Key: SOLR-3425
 URL: https://issues.apache.org/jira/browse/SOLR-3425
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Tommaso Teofili
Priority: Minor
 Fix For: 4.0

 Attachments: SOLR-3425-test.patch


 When programmatically creating cores with a running SolrCloud instance the 
 CloudSolrServer uses the slices nodes information to feed the underlying 
 LBHttpSolrServer so it fails to create cores as there aren't any slices for 
 any new collection (as it's still to be created).
 This happens when using the CloudSolrServer constructor which takes the ZK 
 host as only parameter while it can be avoided by using the constructor which 
 also takes the list of Solr URLs and the underlying LBHttpSolrServer is 
 actually used for making the core creation request.
 However it'd be good to use the ZK host live nodes information to 
 automatically issue a core creation command on one of the underlying Solr 
 hosts without having to specify the full list of URLs beforehand.
 The scenario is when one wants to create a collection with N shards so the 
 client sends N core creation requests for the same collection thus the 
 SolrCloud stuff should just take care of choosing the host where to issue the 
 core creation request and update the cluster state.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3476) Create a Solr Core with a given commit point

2012-05-22 Thread ludovic Boutros (JIRA)


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

ludovic Boutros updated SOLR-3476:
--

Attachment: (was: commitPoint.patch)

 Create a Solr Core with a given commit point
 

 Key: SOLR-3476
 URL: https://issues.apache.org/jira/browse/SOLR-3476
 Project: Solr
  Issue Type: New Feature
  Components: multicore
Affects Versions: 3.6
Reporter: ludovic Boutros
 Attachments: commitPoint.patch


 In some configurations, we need to open new cores with a given commit point.
 For instance, when the publication of new documents must be controlled (legal 
 obligations) in a master-slave configuration there are two cores on the same 
 instanceDir and dataDir which are using two versions of the index.
 The switch of the two cores is done manually.
 The problem is that when the replication is done one day before the switch, 
 if any problem occurs, and we need to restart tomcat, the new documents are 
 published.
 With this functionality, we could ensure that the index generation used by 
 the core used for querying is always the good one. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3476) Create a Solr Core with a given commit point

2012-05-22 Thread ludovic Boutros (JIRA)


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

ludovic Boutros updated SOLR-3476:
--

Attachment: commitPoint.patch

remove some wired things on the beginning of the patch and transform it in unix 
format 

 Create a Solr Core with a given commit point
 

 Key: SOLR-3476
 URL: https://issues.apache.org/jira/browse/SOLR-3476
 Project: Solr
  Issue Type: New Feature
  Components: multicore
Affects Versions: 3.6
Reporter: ludovic Boutros
 Attachments: commitPoint.patch


 In some configurations, we need to open new cores with a given commit point.
 For instance, when the publication of new documents must be controlled (legal 
 obligations) in a master-slave configuration there are two cores on the same 
 instanceDir and dataDir which are using two versions of the index.
 The switch of the two cores is done manually.
 The problem is that when the replication is done one day before the switch, 
 if any problem occurs, and we need to restart tomcat, the new documents are 
 published.
 With this functionality, we could ensure that the index generation used by 
 the core used for querying is always the good one. 

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-3932) Improve load time of .tii files

2012-05-22 Thread Sean Bridges (JIRA)


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

Sean Bridges commented on LUCENE-3932:
--

Can this be ported to 3.6.1

 Improve load time of .tii files
 ---

 Key: LUCENE-3932
 URL: https://issues.apache.org/jira/browse/LUCENE-3932
 Project: Lucene - Java
  Issue Type: Improvement
Affects Versions: 3.5
 Environment: Linux
Reporter: Sean Bridges
Assignee: Michael McCandless
 Fix For: 4.0

 Attachments: LUCENE-3932.trunk.patch, perf.csv


 We have a large 50 gig index which is optimized as one segment, with a 66 MEG 
 .tii file.  This index has no norms, and no field cache.
 It takes about 5 seconds to load this index, profiling reveals that 60% of 
 the time is spent in GrowableWriter.set(index, value), and most of time in 
 set(...) is spent resizing PackedInts.Mutatable current.
 In the constructor for TermInfosReaderIndex, you initialize the writer with 
 the line,
 {quote}GrowableWriter indexToTerms = new GrowableWriter(4, indexSize, 
 false);{quote}
 For our index using four as the bit estimate results in 27 resizes.
 The last value in indexToTerms is going to be ~ tiiFileLength, and if instead 
 you use,
 {quote}int bitEstimate = (int) Math.ceil(Math.log10(tiiFileLength) / 
 Math.log10(2));
 GrowableWriter indexToTerms = new GrowableWriter(bitEstimate, indexSize, 
 false);{quote}
 Load time improves to ~ 2 seconds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (LUCENE-4062) More fine-grained control over the packed integer implementation that is chosen

2012-05-22 Thread Adrien Grand (JIRA)


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

Adrien Grand updated LUCENE-4062:
-

Attachment: LUCENE-4062.patch

Oh right, cases are swapped, I uploaded the wrong patch. Here is a correct 
version.

I guess there are two options:
 1. always writing the most compact form to disk and deserializing it in a fast 
{{PackedInts.Mutable}} implementation (depending on acceptableOverheadRatio),
 2. writing a possibly aligned version on disk (depending on 
acceptableOverheadRatio) and then selecting the fastest PackedInts.Mutable 
implementation that exactly matches bitsPerValue (with no padding bits).

A third option could be to write padding bits ({{Packed64SingleBlock}} 
subclasses may have such padding bits) as well, but I really dislike the fact 
that the on-disk format is implementation-dependent.

Option 1 is likely to make deserialization slower since some decoding might 
occur (the copyData method) but on the other hand, option 2 would prevent us 
from using implementations that add padding bits (such as Packed64SingleBlock21 
which has one padding bit every 3 21-bits integers or Packed64SingleBlock12 
which has 4 padding bits every 5 12-bits integers but not 
Packed64SingleBlock{1,2,4} since 64%{1,2,4}=0).

I initially chose option 1 because I think it is nice to have 
Packed64SingleBlock21 when bitsPerValue is close to 21, since it might be 
significantly faster than Packed64.

In order to know how slower deserialization is (option 1), I ran a 
micro-benchmark which:
  - loads a PackedInts.Reader from a ByteArrayDataInput,
  - performs n random reads on the reader.

Here is the code for the micro-benchmark in case you would like to run it.
{code}
int valueCount = 1000;
int bitsPerValue = 21;
int[] offsets = new int[valueCount];
Random random = new Random();
for (int i = 0; i  valueCount; ++i) {
  offsets[i] = random.nextInt(valueCount);
}
byte[] bytes = new byte[valueCount * 4];
DataOutput out = new ByteArrayDataOutput(bytes);
PackedInts.Writer writer = PackedInts.getWriter(out, valueCount, bitsPerValue);
for (int i = 0; i  valueCount; ++i) {
  writer.add(random.nextInt(1  bitsPerValue));
}
writer.finish();
for (int i = 0; i  50; ++i) {
  long start = System.nanoTime();
  DataInput in = new ByteArrayDataInput(bytes);
  PackedInts.Reader reader = PackedInts.getReader(in, 0f); // Packed64
  // PackedInts.Reader reader = PackedInts.getReader(in, 0.1f); // 
Packed64SingleBlock
  for (int j = 0, n = valueCount; j  n; ++j) {
reader.get(offsets[j]);
  }
  long end = System.nanoTime();
  System.out.println(end - start);
}
{code}

I ran this microbenchmark for bitsPerValue=21 and valueCount in (1 000 000, 10 
000 000). The loading time (n = 0) is 2x to 3x slower with 
Packed64SingleBlock21. However, as soon as you perform valueCount/4 or more 
random reads (n = valueCount/4), the total time is better for 
Packed64SingleBlock21. When n=valueCount, the total time is even 2x better for 
Packed64SingleBlock21.

The loading overhead doesn't seem too bad.

However I guess that some people might still be more interested in the loading 
time than in the query time (for write-intensive applications), but in this 
case they could still request a reader in its compact form (Packed 64 or 
Direct* when bitsPerValue is 8, 16, 32 or 64). If they want to be sure to have 
a fast reader too, they could also make sure that they used 8, 16, 32 or 64 as 
the bitsPerValue parameter of {{PackedInts.getWriter}}.

Mike, what do you think?

 More fine-grained control over the packed integer implementation that is 
 chosen
 ---

 Key: LUCENE-4062
 URL: https://issues.apache.org/jira/browse/LUCENE-4062
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/other
Reporter: Adrien Grand
Assignee: Michael McCandless
Priority: Minor
  Labels: performance
 Fix For: 4.1

 Attachments: LUCENE-4062.patch, LUCENE-4062.patch, LUCENE-4062.patch, 
 LUCENE-4062.patch, LUCENE-4062.patch, LUCENE-4062.patch


 In order to save space, Lucene has two main PackedInts.Mutable implentations, 
 one that is very fast and is based on a byte/short/integer/long array 
 (Direct*) and another one which packs bits in a memory-efficient manner 
 (Packed*).
 The packed implementation tends to be much slower than the direct one, which 
 discourages some Lucene components to use it. On the other hand, if you store 
 21 bits integers in a Direct32, this is a space loss of (32-21)/32=35%.
 If you accept to trade some space for speed, you could store 3 of these 21 
 bits integers in a long, resulting in an overhead of 1/3 bit per value. One 
 advantage of this approach is that you never need to read more than one block

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java6-64 #150

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/150/changes

Changes:

[yonik] use isClosed method

[yonik] tests: turn up logging

--
[...truncated 10786 lines...]
   [junit4] IGNORED 0.00s | CurrencyFieldTest.testPerformance
   [junit4] Cause: Annotated @Ignore()
   [junit4] Completed in 1.89s, 8 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.internal.csv.writer.CSVConfigTest
   [junit4] Completed in 0.02s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.util.DateMathParserTest
   [junit4] Completed in 0.08s, 8 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy1
   [junit4] IGNOR/A 0.02s | TestSolrDeletionPolicy1.testCommitAge
   [junit4] Assumption #1: This test is not working on Windows (or maybe 
machines with only 2 CPUs)
   [junit4]   2 1641 T2671 oas.SolrTestCaseJ4.setUp ###Starting testCommitAge
   [junit4]   2 1648 T2671 C76 oasu.DirectUpdateHandler2.deleteAll 
[collection1] REMOVING ALL DOCUMENTS FROM INDEX
   [junit4]   2 1649 T2671 C76 UPDATE [collection1] webapp=null path=null 
params={} {deleteByQuery=*:*} 0 1
   [junit4]   2 1651 T2671 oas.SolrTestCaseJ4.tearDown ###Ending testCommitAge
   [junit4]   2
   [junit4] Completed in 1.67s, 3 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.LeaderElectionIntegrationTest
   [junit4] Completed in 37.40s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.TestDistributedSearch
   [junit4] Completed in 29.89s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestPhoneticFilterFactory
   [junit4] Completed in 12.73s, 5 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedTermsComponentTest
   [junit4] Completed in 18.87s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.ZkControllerTest
   [junit4] Completed in 20.30s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.TestGroupingSearch
   [junit4] Completed in 6.65s, 12 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestRangeQuery
   [junit4] Completed in 8.40s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterFSTTest
   [junit4] Completed in 1.54s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.ConvertedLegacyTest
   [junit4] Completed in 3.74s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterTest
   [junit4] Completed in 1.52s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.IndexBasedSpellCheckerTest
   [junit4] Completed in 1.45s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.admin.LukeRequestHandlerTest
   [junit4] Completed in 3.21s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestCoreContainer
   [junit4] Completed in 3.40s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy2
   [junit4] Completed in 0.99s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.update.TestIndexingPerformance
   [junit4] Completed in 0.97s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSurroundQueryParser
   [junit4] Completed in 1.14s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.admin.CoreAdminHandlerTest
   [junit4] Completed in 2.42s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.update.DocumentBuilderTest
   [junit4] Completed in 1.08s, 11 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.function.distance.DistanceFunctionTest
   [junit4] Completed in 1.47s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestRemoteStreaming
   [junit4] Completed in 1.31s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.DocumentAnalysisRequestHandlerTest
   [junit4] Completed in 1.14s, 4 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.update.processor.FieldMutatingUpdateProcessorTest
   [junit4] Completed in 0.95s, 20 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.FileBasedSpellCheckerTest
   [junit4] Completed in 1.17s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.response.TestPHPSerializedResponseWriter
   [junit4] Completed in 1.10s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.BadComponentTest
   [junit4] Completed in 0.90s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.IndexReaderFactoryTest
   [junit4] Completed in 1.11s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.highlight.HighlighterConfigTest
   [junit4] Completed in 1.09s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestExtendedDismaxParser
   [junit4] Completed in 10.18s, 8 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.BinaryUpdateRequestHandlerTest
   [junit4] Completed in 1.28s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.IndexSchemaRuntimeFieldTest
   [junit4] Completed in 1.25s, 1 test
   [junit4]

Re: (LUCENE-4062) More fine-grained control over the packed integer implementation that is chosen

2012-05-22 Thread Dawid Weiss

I think you should do something with the read result in that microbenchmark
(a sum is good), otherwise there is a risk of optimizing away most of that
code.
On May 22, 2012 6:18 PM, Adrien Grand (JIRA) j...@apache.org wrote:


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

 Adrien Grand updated LUCENE-4062:
 -

Attachment: LUCENE-4062.patch

 Oh right, cases are swapped, I uploaded the wrong patch. Here is a correct
 version.

 I guess there are two options:
  1. always writing the most compact form to disk and deserializing it in a
 fast {{PackedInts.Mutable}} implementation (depending on
 acceptableOverheadRatio),
  2. writing a possibly aligned version on disk (depending on
 acceptableOverheadRatio) and then selecting the fastest PackedInts.Mutable
 implementation that exactly matches bitsPerValue (with no padding bits).

 A third option could be to write padding bits ({{Packed64SingleBlock}}
 subclasses may have such padding bits) as well, but I really dislike the
 fact that the on-disk format is implementation-dependent.

 Option 1 is likely to make deserialization slower since some decoding
 might occur (the copyData method) but on the other hand, option 2 would
 prevent us from using implementations that add padding bits (such as
 Packed64SingleBlock21 which has one padding bit every 3 21-bits integers or
 Packed64SingleBlock12 which has 4 padding bits every 5 12-bits integers but
 not Packed64SingleBlock{1,2,4} since 64%{1,2,4}=0).

 I initially chose option 1 because I think it is nice to have
 Packed64SingleBlock21 when bitsPerValue is close to 21, since it might be
 significantly faster than Packed64.

 In order to know how slower deserialization is (option 1), I ran a
 micro-benchmark which:
  - loads a PackedInts.Reader from a ByteArrayDataInput,
  - performs n random reads on the reader.

 Here is the code for the micro-benchmark in case you would like to run it.
 {code}
 int valueCount = 1000;
 int bitsPerValue = 21;
 int[] offsets = new int[valueCount];
 Random random = new Random();
 for (int i = 0; i  valueCount; ++i) {
  offsets[i] = random.nextInt(valueCount);
 }
 byte[] bytes = new byte[valueCount * 4];
 DataOutput out = new ByteArrayDataOutput(bytes);
 PackedInts.Writer writer = PackedInts.getWriter(out, valueCount,
 bitsPerValue);
 for (int i = 0; i  valueCount; ++i) {
  writer.add(random.nextInt(1  bitsPerValue));
 }
 writer.finish();
 for (int i = 0; i  50; ++i) {
  long start = System.nanoTime();
  DataInput in = new ByteArrayDataInput(bytes);
  PackedInts.Reader reader = PackedInts.getReader(in, 0f); // Packed64
  // PackedInts.Reader reader = PackedInts.getReader(in, 0.1f); //
 Packed64SingleBlock
  for (int j = 0, n = valueCount; j  n; ++j) {
reader.get(offsets[j]);
  }
  long end = System.nanoTime();
  System.out.println(end - start);
 }
 {code}

 I ran this microbenchmark for bitsPerValue=21 and valueCount in (1 000
 000, 10 000 000). The loading time (n = 0) is 2x to 3x slower with
 Packed64SingleBlock21. However, as soon as you perform valueCount/4 or more
 random reads (n = valueCount/4), the total time is better for
 Packed64SingleBlock21. When n=valueCount, the total time is even 2x better
 for Packed64SingleBlock21.

 The loading overhead doesn't seem too bad.

 However I guess that some people might still be more interested in the
 loading time than in the query time (for write-intensive applications), but
 in this case they could still request a reader in its compact form (Packed
 64 or Direct* when bitsPerValue is 8, 16, 32 or 64). If they want to be
 sure to have a fast reader too, they could also make sure that they used 8,
 16, 32 or 64 as the bitsPerValue parameter of {{PackedInts.getWriter}}.

 Mike, what do you think?

  More fine-grained control over the packed integer implementation that is
 chosen
 
 ---
 
  Key: LUCENE-4062
  URL: https://issues.apache.org/jira/browse/LUCENE-4062
  Project: Lucene - Java
   Issue Type: Improvement
   Components: core/other
 Reporter: Adrien Grand
 Assignee: Michael McCandless
 Priority: Minor
   Labels: performance
  Fix For: 4.1
 
  Attachments: LUCENE-4062.patch, LUCENE-4062.patch,
 LUCENE-4062.patch, LUCENE-4062.patch, LUCENE-4062.patch, LUCENE-4062.patch
 
 
  In order to save space, Lucene has two main PackedInts.Mutable
 implentations, one that is very fast and is based on a
 byte/short/integer/long array (Direct*) and another one which packs bits in
 a memory-efficient manner (Packed*).
  The packed implementation tends to be much slower than the direct one,
 which discourages some Lucene components to use it. On the other hand, if
 you store 21 bits integers in a Direct32, this is a space loss

[jira] [Commented] (LUCENE-4055) Refactor SegmentInfo / FieldInfo to make them extensible

2012-05-22 Thread Robert Muir (JIRA)

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

Robert Muir commented on LUCENE-4055:
-

Just some updates from the work in the branch (scary changes but proceeding
nicely since Mike jumped in and did a lot of it).
Here's a list of the current progress:

* on disk, the segments_N is reduced to the stuff that actually is per-commit:
a list of segments and deleted gens/counts, etc.
* per-segment metadata (doc count, diagnostics, etc) that is write-once is
encoded by the codec, e.g. for 4.0's codec this is in the .si file.
* removed backwards-seeking on segments_N. so appendingcodec still works but
doesn't need any special hacks.
* flush/merge order is changed so that fieldinfos are written last so codecs
have a chance to add metadata to it.
* fieldinfo has a codec metadata api that codec components can use, and that
metadata will be available on reading the segment. this metadata
is for the codec to use to extend fieldinfo, its not carried along during
merge or anything.
* PerFieldPostingsFormat is changed to use the fieldinfo metadata api rather
than a separate .per file (e.g. it records that the id field uses Pulsing).
* all the hairiness involving files() is really nice now, instead we simply
track which files were created, and add them to the .si file. Previously
there was a lot of logic to compute this in a symmetric way at both read and
write time, and if you had a bug, your punishment was FNFE.

not yet done:
* add metadata api to segmentinfo too, so that codec components can record
per-segment information that they care about.
* see if we can implement 3.x's shared doc stores support with segmentinfo
metadata api. This is tricky to do and for addIndexes/indexSplitter etc which
do sneaky things to still work.
* see if we can implement 3.x normGen (separate norms) with segmentinfo
metadata. while in 3.x lucene this was actually per-commit, since 3.x support
is read-only we can effectively treat it as per-segment this way.
* rename stuff so that we have a clearer naming for some of these classes.

I'm also probably missing a few other things. In general I'm pretty happy with
the metadata key-value attributes api versus subclassing.

I tried to make subclassing work, but subclassing turned really ugly fast and
made various codec components too tightly-coupled, e.g.
if someone wants to combine a CompressedStoredFields with a
PerFieldPostingsFormat and SpecialTermVectors, what would the impls be :).

So the overly simple MapString,String avoids these issues, and hey its just
metadata after all so I don't think anything more complex is really needed.

Refactor SegmentInfo / FieldInfo to make them extensible

Key: LUCENE-4055
URL: https://issues.apache.org/jira/browse/LUCENE-4055
Project: Lucene - Java
Issue Type: Improvement
Components: core/codecs
Reporter: Andrzej Bialecki
Assignee: Robert Muir
Fix For: 4.0

After LUCENE-4050 is done the resulting SegmentInfo / FieldInfo classes
should be made abstract so that they can be extended by Codec-s.

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

Jenkins build is back to normal : Lucene-Solr-trunk-Windows-Java6-64 #151

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/151/


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

[jira] [Created] (SOLR-3478) DataImportHandler's Entity must have a name

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

 Summary: DataImportHandler's Entity must have a name
 Key: SOLR-3478
 URL: https://issues.apache.org/jira/browse/SOLR-3478
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: {code}java -Dsolr.solr.home=./example-DIH/solr/ -jar 
start.jar{code}
Reporter: Stefan Matheis (steffkes)
 Fix For: 4.0


Using trunk and trying to start the {{example-DIH}} version, throws the 
following Exception:

{code}May 22, 2012 8:17:45 PM org.apache.solr.common.SolrException log
SEVERE: null:org.apache.solr.common.SolrException
  at org.apache.solr.core.SolrCore.init(SolrCore.java:614)
  [...]
Caused by: org.apache.solr.handler.dataimport.DataImportHandlerException: 
Entity must have a name.
  at org.apache.solr.handler.dataimport.config.Entity.init(Entity.java:54)
  at 
org.apache.solr.handler.dataimport.config.DIHConfiguration.init(DIHConfiguration.java:61)
  at 
org.apache.solr.handler.dataimport.DataImporter.readFromXml(DataImporter.java:249)
  at 
org.apache.solr.handler.dataimport.DataImporter.loadDataConfig(DataImporter.java:187)
  ... 49 more{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (SOLR-3478) DataImportHandler's Entity must have a name


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

Stefan Matheis (steffkes) reassigned SOLR-3478:
---

Assignee: Stefan Matheis (steffkes)

 DataImportHandler's Entity must have a name
 ---

 Key: SOLR-3478
 URL: https://issues.apache.org/jira/browse/SOLR-3478
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: {code}java -Dsolr.solr.home=./example-DIH/solr/ -jar 
 start.jar{code}
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0

 Attachments: SOLR-3478.patch


 Using trunk and trying to start the {{example-DIH}} version, throws the 
 following Exception:
 {code}May 22, 2012 8:17:45 PM org.apache.solr.common.SolrException log
 SEVERE: null:org.apache.solr.common.SolrException
   at org.apache.solr.core.SolrCore.init(SolrCore.java:614)
   [...]
 Caused by: org.apache.solr.handler.dataimport.DataImportHandlerException: 
 Entity must have a name.
   at org.apache.solr.handler.dataimport.config.Entity.init(Entity.java:54)
   at 
 org.apache.solr.handler.dataimport.config.DIHConfiguration.init(DIHConfiguration.java:61)
   at 
 org.apache.solr.handler.dataimport.DataImporter.readFromXml(DataImporter.java:249)
   at 
 org.apache.solr.handler.dataimport.DataImporter.loadDataConfig(DataImporter.java:187)
   ... 49 more{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3478) DataImportHandler's Entity must have a name


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

Stefan Matheis (steffkes) updated SOLR-3478:


Attachment: SOLR-3478.patch

 DataImportHandler's Entity must have a name
 ---

 Key: SOLR-3478
 URL: https://issues.apache.org/jira/browse/SOLR-3478
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: {code}java -Dsolr.solr.home=./example-DIH/solr/ -jar 
 start.jar{code}
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0

 Attachments: SOLR-3478.patch


 Using trunk and trying to start the {{example-DIH}} version, throws the 
 following Exception:
 {code}May 22, 2012 8:17:45 PM org.apache.solr.common.SolrException log
 SEVERE: null:org.apache.solr.common.SolrException
   at org.apache.solr.core.SolrCore.init(SolrCore.java:614)
   [...]
 Caused by: org.apache.solr.handler.dataimport.DataImportHandlerException: 
 Entity must have a name.
   at org.apache.solr.handler.dataimport.config.Entity.init(Entity.java:54)
   at 
 org.apache.solr.handler.dataimport.config.DIHConfiguration.init(DIHConfiguration.java:61)
   at 
 org.apache.solr.handler.dataimport.DataImporter.readFromXml(DataImporter.java:249)
   at 
 org.apache.solr.handler.dataimport.DataImporter.loadDataConfig(DataImporter.java:187)
   ... 49 more{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3478) DataImportHandler's Entity must have a name


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

Stefan Matheis (steffkes) updated SOLR-3478:


Environment: r1341454, {code}java -Dsolr.solr.home=./example-DIH/solr/ 
-jar start.jar{code}  (was: {code}java -Dsolr.solr.home=./example-DIH/solr/ 
-jar start.jar{code})

 DataImportHandler's Entity must have a name
 ---

 Key: SOLR-3478
 URL: https://issues.apache.org/jira/browse/SOLR-3478
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: r1341454, {code}java 
 -Dsolr.solr.home=./example-DIH/solr/ -jar start.jar{code}
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0

 Attachments: SOLR-3478.patch


 Using trunk and trying to start the {{example-DIH}} version, throws the 
 following Exception:
 {code}May 22, 2012 8:17:45 PM org.apache.solr.common.SolrException log
 SEVERE: null:org.apache.solr.common.SolrException
   at org.apache.solr.core.SolrCore.init(SolrCore.java:614)
   [...]
 Caused by: org.apache.solr.handler.dataimport.DataImportHandlerException: 
 Entity must have a name.
   at org.apache.solr.handler.dataimport.config.Entity.init(Entity.java:54)
   at 
 org.apache.solr.handler.dataimport.config.DIHConfiguration.init(DIHConfiguration.java:61)
   at 
 org.apache.solr.handler.dataimport.DataImporter.readFromXml(DataImporter.java:249)
   at 
 org.apache.solr.handler.dataimport.DataImporter.loadDataConfig(DataImporter.java:187)
   ... 49 more{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3478) DataImportHandler's Entity must have a name


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

James Dyer commented on SOLR-3478:
--

Thanks for finding this one.  Looking at this issue, I'm pretty sure I 
introduced this bug with SOLR-3430.

 DataImportHandler's Entity must have a name
 ---

 Key: SOLR-3478
 URL: https://issues.apache.org/jira/browse/SOLR-3478
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
 Environment: r1341454, {code}java 
 -Dsolr.solr.home=./example-DIH/solr/ -jar start.jar{code}
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
 Fix For: 4.0

 Attachments: SOLR-3478.patch


 Using trunk and trying to start the {{example-DIH}} version, throws the 
 following Exception:
 {code}May 22, 2012 8:17:45 PM org.apache.solr.common.SolrException log
 SEVERE: null:org.apache.solr.common.SolrException
   at org.apache.solr.core.SolrCore.init(SolrCore.java:614)
   [...]
 Caused by: org.apache.solr.handler.dataimport.DataImportHandlerException: 
 Entity must have a name.
   at org.apache.solr.handler.dataimport.config.Entity.init(Entity.java:54)
   at 
 org.apache.solr.handler.dataimport.config.DIHConfiguration.init(DIHConfiguration.java:61)
   at 
 org.apache.solr.handler.dataimport.DataImporter.readFromXml(DataImporter.java:249)
   at 
 org.apache.solr.handler.dataimport.DataImporter.loadDataConfig(DataImporter.java:187)
   ... 49 more{code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Build failed in Jenkins: Lucene-Solr-trunk-Linux-Java6-64 #445

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/445/

--
[...truncated 11133 lines...]
   [junit4] Suite: org.apache.solr.search.function.SortByFunctionTest
   [junit4] Completed on J1 in 1.15s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.BadIndexSchemaTest
   [junit4] Completed on J0 in 0.67s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.EchoParamsTest
   [junit4] Completed on J0 in 0.10s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.update.DocumentBuilderTest
   [junit4] Completed on J1 in 0.51s, 11 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestReversedWildcardFilterFactory
   [junit4] Completed on J0 in 0.53s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterWFSTTest
   [junit4] Completed on J1 in 0.68s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.CopyFieldTest
   [junit4] Completed on J1 in 0.51s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestFoldingMultitermQuery
   [junit4] Completed on J1 in 0.95s, 18 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.CurrencyFieldTest
   [junit4] IGNORED 0.00s J1 | CurrencyFieldTest.testPerformance
   [junit4] Cause: Annotated @Ignore()
   [junit4] Completed on J1 in 0.91s, 8 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.TestOmitPositions
   [junit4] Completed on J1 in 0.52s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy1
   [junit4] Completed on J1 in 0.79s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.RequestHandlersTest
   [junit4] Completed on J1 in 0.68s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestDocSet
   [junit4] Completed on J1 in 0.67s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.FileBasedSpellCheckerTest
   [junit4] Completed on J1 in 0.63s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.DisMaxRequestHandlerTest
   [junit4] Completed on J1 in 0.67s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestQuerySenderNoQuery
   [junit4] Completed on J1 in 0.45s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestMergePolicyConfig
   [junit4] Completed on J1 in 0.43s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.UUIDFieldTest
   [junit4] Completed on J1 in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSearchPerf
   [junit4] Completed on J1 in 0.60s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestJapaneseBaseFormFilterFactory
   [junit4] Completed on J1 in 0.30s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.SampleTest
   [junit4] Completed on J1 in 0.22s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestJapaneseTokenizerFactory
   [junit4] Completed on J1 in 0.01s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestJmxMonitoredMap
   [junit4] Completed on J1 in 0.37s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestCodecSupport
   [junit4] Completed on J1 in 0.13s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.TestPluginEnable
   [junit4] Completed on J1 in 0.08s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestHTMLStripCharFilterFactory
   [junit4] Completed on J1 in 0.02s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.SpellPossibilityIteratorTest
   [junit4] Completed on J1 in 0.06s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.PluginInfoTest
   [junit4] Completed on J1 in 0.05s, 9 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.OpenExchangeRatesOrgProviderTest
   [junit4] Completed on J1 in 0.02s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestNGramFilters
   [junit4] Completed on J1 in 0.02s, 10 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestPortugueseStemFilterFactory
   [junit4] Completed on J1 in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestSynonymFilterFactory
   [junit4] Completed on J1 in 0.01s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.SnowballPorterFilterFactoryTest
   [junit4] Completed on J1 in 0.01s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestLatvianStemFilterFactory
   [junit4] Completed on J1 in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.util.DOMUtilTest
   [junit4] Completed on J1 in 0.02s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestCJKTokenizerFactory
   [junit4] Completed on J1 in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestNorwegianLightStemFilterFactory
   [junit4] Completed on J1 in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestHunspellStemFilterFactory
   [junit4] Completed on J1 in 0.01s, 1 test
   [junit4]

Re: Using term offsets for hit highlighting

2012-05-22 Thread Alan Woodward

Hey, I reckon I can have a decent go at getting the branch updated.  Is it best 
to work this out as a patch applying to trunk?  Any patch that merges in all 
the trunk changes to the branch is going to be absolutely massive…

On 17 May 2012, at 13:15, Simon Willnauer wrote:

 ok man. I will try to merge up the branch. I tell you this is going to
 be messy and it might not compile but I will make it reasonable so you
 can start.
 
 simon
 
 On Thu, May 17, 2012 at 8:03 AM, Alan Woodward
 alan.woodw...@romseysoftware.co.uk wrote:
 Sorry for vanishing for so long, life unexpectedly caught up with me...  I'm 
 going to have some time to look at this again next week though, if you're 
 interested in picking it up again.
 
 On 21 Mar 2012, at 09:02, Alan Woodward wrote:
 
 That would be great, thanks!  I had a go at merging it last night, but 
 there are a *lot* of changes that I haven't got my head round yet, so it 
 was getting pretty messy.
 
 On 21 Mar 2012, at 08:49, Simon Willnauer wrote:
 
 Alan, if you want I can just merge the branch up next week and we
 iterate from there?
 
 simon
 
 On Tue, Mar 20, 2012 at 12:34 PM, Erick Erickson
 erickerick...@gmail.com wrote:
 Yep, the first challenge is always getting the old patch(es) to apply.
 
 On Tue, Mar 20, 2012 at 4:09 AM, Alan Woodward
 alan.woodw...@romseysoftware.co.uk wrote:
 Thanks for all the offers of help!  It looks as though most of the hard 
 work has already been done, which is exactly where I like to pick up 
 projects.  :-)
 
 Maybe the best place to start would be for me to rebase the branch 
 against trunk, and see what still fits?  I think there have been some 
 fairly major changes in the internals since July last year.
 
 On 19 Mar 2012, at 17:07, Mike Sokolov wrote:
 
 I posted a patch with a Collector somewhat similar to what you 
 described, Alan - it's attached to one of the sub-issues 
 https://issues.apache.org/jira/browse/LUCENE-3318.   It is in a fairly 
 complete alpha state, but has seen no production use of course, since 
 it relies on the remainder of the unfinished work in that branch.  It 
 works by creating a TokenStream based on match positions returned from 
 the query and passing that to the existing Highlighter.  Please feel 
 free to get in touch if you decide to look into that and have questions.
 
 
 -Mike
 
 On 03/19/2012 11:51 AM, Simon Willnauer wrote:
 On Mon, Mar 19, 2012 at 4:50 PM, Uwe Schindleru...@thetaphi.de  
 wrote:
 
 Have you marked that for GSOC? Would be a good idea!
 
 yes I did
 
 -
 Uwe Schindler
 H.-H.-Meier-Allee 63, D-28213 Bremen
 http://www.thetaphi.de
 eMail: u...@thetaphi.de
 
 
 
 -Original Message-
 From: Simon Willnauer [mailto:simon.willna...@googlemail.com]
 Sent: Monday, March 19, 2012 4:43 PM
 To: dev@lucene.apache.org
 Subject: Re: Using term offsets for hit highlighting
 
 Alan, you made my day!
 
 The branch is kind of outdated but I looked at it lately and I can 
 certainly help
 to get it up to speed. The feature in that branch is quite a big one 
 and its in a
 very early stage. Still I want to encourage you to take a look and 
 work on it. I
 promise all my help with the issues!
 
 let me know if you have questions!
 
 simon
 
 On Mon, Mar 19, 2012 at 3:52 PM, Alan Woodward
 alan.woodw...@romseysoftware.co.uk  wrote:
 
 Cool, thanks Robert.  I'll take a look at the JIRA ticket.
 
 On 19 Mar 2012, at 14:44, Robert Muir wrote:
 
 
 On Mon, Mar 19, 2012 at 10:38 AM, Alan Woodward
 alan.woodw...@romseysoftware.co.uk  wrote:
 
 Hello,
 
 The project I'm currently working on requires the reporting of 
 exact
 hit positions from some pretty hairy queries, not all of which are
 covered by the existing highlighter modules.  I'm working round 
 this
 by translating everything into SpanQueries, and using the 
 getSpans()
 method to locate hits (I've extended the Spans interface to make
 term offsets available - see
 https://issues.apache.org/jira/browse/LUCENE-3826).  This works 
 for
 our use-case, but isn't terribly efficient, and obviously isn't 
 applicable to
 
 non-Span queries.
 
 I've seen a bit of chatter on the list about using term offsets to
 provide accurate highlighting in Lucene.  I'm going to have a 
 couple
 of weeks free in April, and I thought I might have a go at
 implementing this.  Mainly I'm wondering if there's already been
 thoughts about how to do it.  My current thoughts are to somehow
 extend the Weight and Scorer interface to make term offsets
 available; to get highlights for a given set of documents, you'd
 essentially run the query again, with a filter on just the 
 documents
 you want highlighted, and have a custom collector that gets the 
 term
 
 offsets in place of the scores.
 
 
 Hi Alan, Simon started some initial work on
 https://issues.apache.org/jira/browse/LUCENE-2878
 
 Some work and prototypes were done in a branch, but it might be
 lagging behind trunk a bit.
 
 Additionally at the time it was first done, I think we didn't

Jenkins build is back to normal : Lucene-Solr-trunk-Linux-Java6-64 #446

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/446/


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

[jira] [Resolved] (SOLR-1205) add a field alias feature


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

Hoss Man resolved SOLR-1205.


   Resolution: Fixed
Fix Version/s: (was: 4.1)
   4.0

This was implemented via the DocTransformer feature added to the fl param...

http://wiki.apache.org/solr/CommonQueryParameters#Field_alias

 add a field alias feature
 -

 Key: SOLR-1205
 URL: https://issues.apache.org/jira/browse/SOLR-1205
 Project: Solr
  Issue Type: New Feature
Reporter: Noble Paul
 Fix For: 4.0


 A feature which is similar to the SQL 'as' can be helpful 
 see the mail thread
 http://www.lucidimagination.com/search/document/63b63edc15092922/customizing_results#63b63edc15092922
 it can be implemented as a separate request param
 say 
 {code}
 fl.alias=from_name1:to_name1fl.alias=from_name2:to_name2
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (SOLR-1205) add a field alias feature


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

Hoss Man reassigned SOLR-1205:
--

Assignee: Hoss Man

 add a field alias feature
 -

 Key: SOLR-1205
 URL: https://issues.apache.org/jira/browse/SOLR-1205
 Project: Solr
  Issue Type: New Feature
Reporter: Noble Paul
Assignee: Hoss Man
 Fix For: 4.0


 A feature which is similar to the SQL 'as' can be helpful 
 see the mail thread
 http://www.lucidimagination.com/search/document/63b63edc15092922/customizing_results#63b63edc15092922
 it can be implemented as a separate request param
 say 
 {code}
 fl.alias=from_name1:to_name1fl.alias=from_name2:to_name2
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Assigned] (SOLR-1205) add a field alias feature


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

Hoss Man reassigned SOLR-1205:
--

Assignee: Ryan McKinley  (was: Hoss Man)

 add a field alias feature
 -

 Key: SOLR-1205
 URL: https://issues.apache.org/jira/browse/SOLR-1205
 Project: Solr
  Issue Type: New Feature
Reporter: Noble Paul
Assignee: Ryan McKinley
 Fix For: 4.0


 A feature which is similar to the SQL 'as' can be helpful 
 see the mail thread
 http://www.lucidimagination.com/search/document/63b63edc15092922/customizing_results#63b63edc15092922
 it can be implemented as a separate request param
 say 
 {code}
 fl.alias=from_name1:to_name1fl.alias=from_name2:to_name2
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Build failed in Jenkins: Lucene-Solr-trunk-Linux-Java7-64 #93

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java7-64/93/

--
[...truncated 14527 lines...]
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:814)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:875)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:889)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
   [junit4]   2at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
   [junit4]   2at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
   [junit4]   2at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
   [junit4]   2at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
   [junit4]   2at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
   [junit4]   2at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:821)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:669)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:695)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:734)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:745)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
   [junit4]   2at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
   [junit4]   2at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
   [junit4]   2at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
   [junit4]   2at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
   [junit4]   2at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
   [junit4]   2at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
   [junit4]   2at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
   [junit4]   2at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
   [junit4]   2at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:56)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)
   [junit4]   2
   [junit4]   2 591 T86 C7 oashd.SolrWriter.rollback SEVERE Exception while 
solr rollback. org.apache.lucene.index.IndexNotFoundException: no segments* 
file found in MockDirWrapper(org.apache.lucene.store.RAMDirectory@5a347342 
lockFactory=org.apache.lucene.store.NativeFSLockFactory@5286fcc4): files: []
   [junit4]   2at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:607)
   [junit4]   2at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:497)
   [junit4]   2at 
org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:326)
   [junit4]   2

[JENKINS] Lucene-Solr-tests-only-trunk - Build # 14266 - Failure

2012-05-22 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/14266/

1 tests failed.
FAILED:  
junit.framework.TestSuite.org.apache.solr.handler.TestReplicationHandler

Error Message:
ERROR: SolrIndexSearcher opens=74 closes=73

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=74 closes=73
at __randomizedtesting.SeedInfo.seed([380F8DD0CD7FC858]:0)
at org.junit.Assert.fail(Assert.java:93)
at 
org.apache.solr.SolrTestCaseJ4.endTrackingSearchers(SolrTestCaseJ4.java:190)
at org.apache.solr.SolrTestCaseJ4.afterClass(SolrTestCaseJ4.java:82)
at sun.reflect.GeneratedMethodAccessor15.invoke(Unknown Source)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:752)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at 
org.apache.lucene.util.TestRuleIcuHack$1.evaluate(TestRuleIcuHack.java:51)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at 
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:56)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)




Build Log (for compile errors):
[...truncated 10333 lines...]



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

[jira] [Commented] (LUCENE-4062) More fine-grained control over the packed integer implementation that is chosen

2012-05-22 Thread Dawid Weiss (JIRA)


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

Dawid Weiss commented on LUCENE-4062:
-

Hi Adrien. I wrote back to dev list, don't know if you caught that -- the 
benchmark could probably be improved by calculating something off reader.get() 
because otherwise it's a pure read without side effects and can be removed by 
the jit (or at least optimized in unpredictable ways). A rolling sum or 
something will probably do.

 More fine-grained control over the packed integer implementation that is 
 chosen
 ---

 Key: LUCENE-4062
 URL: https://issues.apache.org/jira/browse/LUCENE-4062
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/other
Reporter: Adrien Grand
Assignee: Michael McCandless
Priority: Minor
  Labels: performance
 Fix For: 4.1

 Attachments: LUCENE-4062.patch, LUCENE-4062.patch, LUCENE-4062.patch, 
 LUCENE-4062.patch, LUCENE-4062.patch, LUCENE-4062.patch


 In order to save space, Lucene has two main PackedInts.Mutable implentations, 
 one that is very fast and is based on a byte/short/integer/long array 
 (Direct*) and another one which packs bits in a memory-efficient manner 
 (Packed*).
 The packed implementation tends to be much slower than the direct one, which 
 discourages some Lucene components to use it. On the other hand, if you store 
 21 bits integers in a Direct32, this is a space loss of (32-21)/32=35%.
 If you accept to trade some space for speed, you could store 3 of these 21 
 bits integers in a long, resulting in an overhead of 1/3 bit per value. One 
 advantage of this approach is that you never need to read more than one block 
 to read or write a value, so this can be significantly faster than Packed32 
 and Packed64 which always need to read/write two blocks in order to avoid 
 costly branches.
 I ran some tests, and for 1000 21 bits values, this implementation takes 
 less than 2% more space and has 44% faster writes and 30% faster reads. The 
 12 bits version (5 values per block) has the same performance improvement and 
 a 6% memory overhead compared to the packed implementation.
 In order to select the best implementation for a given integer size, I wrote 
 the {{PackedInts.getMutable(valueCount, bitsPerValue, 
 acceptableOverheadPerValue)}} method. This method select the fastest 
 implementation that has less than {{acceptableOverheadPerValue}} wasted bits 
 per value. For example, if you accept an overhead of 20% 
 ({{acceptableOverheadPerValue = 0.2f * bitsPerValue}}), which is pretty 
 reasonable, here is what implementations would be selected:
  * 1: Packed64SingleBlock1
  * 2: Packed64SingleBlock2
  * 3: Packed64SingleBlock3
  * 4: Packed64SingleBlock4
  * 5: Packed64SingleBlock5
  * 6: Packed64SingleBlock6
  * 7: Direct8
  * 8: Direct8
  * 9: Packed64SingleBlock9
  * 10: Packed64SingleBlock10
  * 11: Packed64SingleBlock12
  * 12: Packed64SingleBlock12
  * 13: Packed64
  * 14: Direct16
  * 15: Direct16
  * 16: Direct16
  * 17: Packed64
  * 18: Packed64SingleBlock21
  * 19: Packed64SingleBlock21
  * 20: Packed64SingleBlock21
  * 21: Packed64SingleBlock21
  * 22: Packed64
  * 23: Packed64
  * 24: Packed64
  * 25: Packed64
  * 26: Packed64
  * 27: Direct32
  * 28: Direct32
  * 29: Direct32
  * 30: Direct32
  * 31: Direct32
  * 32: Direct32
  * 33: Packed64
  * 34: Packed64
  * 35: Packed64
  * 36: Packed64
  * 37: Packed64
  * 38: Packed64
  * 39: Packed64
  * 40: Packed64
  * 41: Packed64
  * 42: Packed64
  * 43: Packed64
  * 44: Packed64
  * 45: Packed64
  * 46: Packed64
  * 47: Packed64
  * 48: Packed64
  * 49: Packed64
  * 50: Packed64
  * 51: Packed64
  * 52: Packed64
  * 53: Packed64
  * 54: Direct64
  * 55: Direct64
  * 56: Direct64
  * 57: Direct64
  * 58: Direct64
  * 59: Direct64
  * 60: Direct64
  * 61: Direct64
  * 62: Direct64
 Under 32 bits per value, only 13, 17 and 22-26 bits per value would still 
 choose the slower Packed64 implementation. Allowing a 50% overhead would 
 prevent the packed implementation to be selected for bits per value under 32. 
 Allowing an overhead of 32 bits per value would make sure that a Direct* 
 implementation is always selected.
 Next steps would be to:
  * make lucene components use this {{getMutable}} method and let users decide 
 what trade-off better suits them,
  * write a Packed32SingleBlock implementation if necessary (I didn't do it 
 because I have no 32-bits computer to test the performance improvements).
 I think this would allow more fine-grained control over the speed/space 
 trade-off, what do you think?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact

Build failed in Jenkins: Lucene-Solr-trunk-Linux-Java6-64 #449

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/449/

--
[...truncated 11137 lines...]
   [junit4]   2at 
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:312)
   [junit4]   2at 
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:309)
   [junit4]   2at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:65)
   [junit4]   2at 
org.apache.solr.common.cloud.SolrZkClient.setData(SolrZkClient.java:309)
   [junit4]   2at 
org.apache.solr.common.cloud.SolrZkClient.setData(SolrZkClient.java:545)
   [junit4]   2at 
org.apache.solr.cloud.ZkController.publishState(ZkController.java:1058)
   [junit4]   2... 5 more
   [junit4]   2 
   [junit4]   2 107151 T1695 C16 P36525 oasc.RecoveryStrategy.doRecovery 
SEVERE Recovery failed - trying again...
   [junit4]   2  C16_STATE=coll:oneInstanceCollection2 
core:oneInstanceCollection22 props:{shard=slice2, roles=none, state=recovering, 
core=oneInstanceCollection22, collection=oneInstanceCollection2, 
node_name=127.0.0.1:36525_solr, base_url=http://127.0.0.1:36525/solr}
   [junit4]   2 52 T1695 C16 P36525 oasc.RecoveryStrategy.doRecovery 
SEVERE Error while trying to recover. 
org.apache.solr.common.cloud.ZooKeeperException: could not publish node state
   [junit4]   2at 
org.apache.solr.cloud.ZkController.publishState(ZkController.java:1062)
   [junit4]   2at 
org.apache.solr.cloud.ZkController.doPublish(ZkController.java:1038)
   [junit4]   2at 
org.apache.solr.cloud.ZkController.publishState(ZkController.java:1021)
   [junit4]   2at 
org.apache.solr.cloud.ZkController.publish(ZkController.java:781)
   [junit4]   2at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:275)
   [junit4]   2at 
org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:207)
   [junit4]   2 Caused by: 
org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = 
Session expired for /node_states/127.0.0.1:36525_solr
   [junit4]   2at 
org.apache.zookeeper.KeeperException.create(KeeperException.java:118)
   [junit4]   2at 
org.apache.zookeeper.KeeperException.create(KeeperException.java:42)
   [junit4]   2at 
org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1044)
   [junit4]   2at 
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:312)
   [junit4]   2at 
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:309)
   [junit4]   2at 
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:65)
   [junit4]   2at 
org.apache.solr.common.cloud.SolrZkClient.setData(SolrZkClient.java:309)
   [junit4]   2at 
org.apache.solr.common.cloud.SolrZkClient.setData(SolrZkClient.java:545)
   [junit4]   2at 
org.apache.solr.cloud.ZkController.publishState(ZkController.java:1058)
   [junit4]   2... 5 more
   [junit4]   2 
   [junit4]   2 52 T1695 C16 P36525 oasc.RecoveryStrategy.doRecovery 
SEVERE Recovery failed - trying again...
   [junit4]   2  C16_STATE=coll:oneInstanceCollection2 
core:oneInstanceCollection22 props:{shard=slice2, roles=none, state=recovering, 
core=oneInstanceCollection22, collection=oneInstanceCollection2, 
node_name=127.0.0.1:36525_solr, base_url=http://127.0.0.1:36525/solr}
   [junit4]   2 115253 T1695 C16 P36525 oasc.RecoveryStrategy.doRecovery 
SEVERE Error while trying to recover. 
org.apache.solr.common.cloud.ZooKeeperException: could not publish node state
   [junit4]   2at 
org.apache.solr.cloud.ZkController.publishState(ZkController.java:1062)
   [junit4]   2at 
org.apache.solr.cloud.ZkController.doPublish(ZkController.java:1038)
   [junit4]   2at 
org.apache.solr.cloud.ZkController.publishState(ZkController.java:1021)
   [junit4]   2at 
org.apache.solr.cloud.ZkController.publish(ZkController.java:781)
   [junit4]   2at 
org.apache.solr.cloud.RecoveryStrategy.doRecovery(RecoveryStrategy.java:275)
   [junit4]   2at 
org.apache.solr.cloud.RecoveryStrategy.run(RecoveryStrategy.java:207)
   [junit4]   2 Caused by: 
org.apache.zookeeper.KeeperException$SessionExpiredException: KeeperErrorCode = 
Session expired for /node_states/127.0.0.1:36525_solr
   [junit4]   2at 
org.apache.zookeeper.KeeperException.create(KeeperException.java:118)
   [junit4]   2at 
org.apache.zookeeper.KeeperException.create(KeeperException.java:42)
   [junit4]   2at 
org.apache.zookeeper.ZooKeeper.setData(ZooKeeper.java:1044)
   [junit4]   2at 
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:312)
   [junit4]   2at 
org.apache.solr.common.cloud.SolrZkClient$8.execute(SolrZkClient.java:309)
   [junit4]   2at

[jira] [Updated] (SOLR-2585) Context-Sensitive Spelling Suggestions Collations


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

James Dyer updated SOLR-2585:
-

Attachment: SOLR-2585.patch

fixes a distributed bug.  This might be ready to commit.

 Context-Sensitive Spelling Suggestions  Collations
 ---

 Key: SOLR-2585
 URL: https://issues.apache.org/jira/browse/SOLR-2585
 Project: Solr
  Issue Type: Improvement
  Components: spellchecker
Affects Versions: 4.0
Reporter: James Dyer
Priority: Minor
 Attachments: SOLR-2585.patch, SOLR-2585.patch, SOLR-2585.patch, 
 SOLR-2585.patch, SOLR-2585.patch, SOLR-2585.patch, SOLR-2585.patch, 
 SOLR-2585.patch, SOLR-2585.patch, SOLR-2585.patch


 Solr currently cannot offer what I'm calling here a context-sensitive 
 spelling suggestion.  That is, if a user enters one or more words that have 
 docFrequency  0, but nevertheless are misspelled, then no suggestions are 
 offered.  Currently, Solr will always consider a word correctly spelled if 
 it is in the index and/or dictionary, regardless of context.  This issue  
 patch add support for context-sensitive spelling suggestions. 
 See SpellCheckCollatorTest.testContextSensitiveCollate() for a the typical 
 use case for this functionality.  This tests both using 
 IndexBasedSepllChecker and DirectSolrSpellChecker. 
 Two new Spelling Parameters were added:
   - spellcheck.alternativeTermCount - The count of suggestions to return for 
 each query term existing in the index and/or dictionary.  Presumably, users 
 will want fewer suggestions for words with docFrequency0.  Also setting this 
 value turns on context-sensitive spell suggestions. 
   - spellcheck.maxResultsForSuggest - The maximum number of hits the request 
 can return in order to both generate spelling suggestions and set the 
 correctlySpelled element to false.  For example, if this is set to 5 and 
 the user's query returns 5 or fewer results, the spellchecker will report 
 correctlySpelled=false and also offer suggestions (and collations if 
 requested).  Setting this greater than zero is useful for creating 
 did-you-mean suggestions for queries that return a low number of hits.
 I have also included a test using shards.  See additions to 
 DistributedSpellCheckComponentTest. 
 In Lucene, SpellChecker.java can already support this functionality (by 
 passing a null IndexReader and field-name).  The DirectSpellChecker, however, 
 needs a minor enhancement.  This gives the option to allow DirectSpellChecker 
 to return suggestions for all query terms regardless of frequency.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Jenkins build is back to normal : Lucene-Solr-trunk-Linux-Java6-64 #450

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java6-64/450/


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

[jira] [Commented] (LUCENE-4062) More fine-grained control over the packed integer implementation that is chosen

2012-05-22 Thread Adrien Grand (JIRA)


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

Adrien Grand commented on LUCENE-4062:
--

Good catch, David. I modified the code to perform a rolling sum and the results 
are actually a little different. Packed64SingleBlock21 is now faster than 
Packed64 when n=valueCount (instead of valueCount/4).



 More fine-grained control over the packed integer implementation that is 
 chosen
 ---

 Key: LUCENE-4062
 URL: https://issues.apache.org/jira/browse/LUCENE-4062
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/other
Reporter: Adrien Grand
Assignee: Michael McCandless
Priority: Minor
  Labels: performance
 Fix For: 4.1

 Attachments: LUCENE-4062.patch, LUCENE-4062.patch, LUCENE-4062.patch, 
 LUCENE-4062.patch, LUCENE-4062.patch, LUCENE-4062.patch


 In order to save space, Lucene has two main PackedInts.Mutable implentations, 
 one that is very fast and is based on a byte/short/integer/long array 
 (Direct*) and another one which packs bits in a memory-efficient manner 
 (Packed*).
 The packed implementation tends to be much slower than the direct one, which 
 discourages some Lucene components to use it. On the other hand, if you store 
 21 bits integers in a Direct32, this is a space loss of (32-21)/32=35%.
 If you accept to trade some space for speed, you could store 3 of these 21 
 bits integers in a long, resulting in an overhead of 1/3 bit per value. One 
 advantage of this approach is that you never need to read more than one block 
 to read or write a value, so this can be significantly faster than Packed32 
 and Packed64 which always need to read/write two blocks in order to avoid 
 costly branches.
 I ran some tests, and for 1000 21 bits values, this implementation takes 
 less than 2% more space and has 44% faster writes and 30% faster reads. The 
 12 bits version (5 values per block) has the same performance improvement and 
 a 6% memory overhead compared to the packed implementation.
 In order to select the best implementation for a given integer size, I wrote 
 the {{PackedInts.getMutable(valueCount, bitsPerValue, 
 acceptableOverheadPerValue)}} method. This method select the fastest 
 implementation that has less than {{acceptableOverheadPerValue}} wasted bits 
 per value. For example, if you accept an overhead of 20% 
 ({{acceptableOverheadPerValue = 0.2f * bitsPerValue}}), which is pretty 
 reasonable, here is what implementations would be selected:
  * 1: Packed64SingleBlock1
  * 2: Packed64SingleBlock2
  * 3: Packed64SingleBlock3
  * 4: Packed64SingleBlock4
  * 5: Packed64SingleBlock5
  * 6: Packed64SingleBlock6
  * 7: Direct8
  * 8: Direct8
  * 9: Packed64SingleBlock9
  * 10: Packed64SingleBlock10
  * 11: Packed64SingleBlock12
  * 12: Packed64SingleBlock12
  * 13: Packed64
  * 14: Direct16
  * 15: Direct16
  * 16: Direct16
  * 17: Packed64
  * 18: Packed64SingleBlock21
  * 19: Packed64SingleBlock21
  * 20: Packed64SingleBlock21
  * 21: Packed64SingleBlock21
  * 22: Packed64
  * 23: Packed64
  * 24: Packed64
  * 25: Packed64
  * 26: Packed64
  * 27: Direct32
  * 28: Direct32
  * 29: Direct32
  * 30: Direct32
  * 31: Direct32
  * 32: Direct32
  * 33: Packed64
  * 34: Packed64
  * 35: Packed64
  * 36: Packed64
  * 37: Packed64
  * 38: Packed64
  * 39: Packed64
  * 40: Packed64
  * 41: Packed64
  * 42: Packed64
  * 43: Packed64
  * 44: Packed64
  * 45: Packed64
  * 46: Packed64
  * 47: Packed64
  * 48: Packed64
  * 49: Packed64
  * 50: Packed64
  * 51: Packed64
  * 52: Packed64
  * 53: Packed64
  * 54: Direct64
  * 55: Direct64
  * 56: Direct64
  * 57: Direct64
  * 58: Direct64
  * 59: Direct64
  * 60: Direct64
  * 61: Direct64
  * 62: Direct64
 Under 32 bits per value, only 13, 17 and 22-26 bits per value would still 
 choose the slower Packed64 implementation. Allowing a 50% overhead would 
 prevent the packed implementation to be selected for bits per value under 32. 
 Allowing an overhead of 32 bits per value would make sure that a Direct* 
 implementation is always selected.
 Next steps would be to:
  * make lucene components use this {{getMutable}} method and let users decide 
 what trade-off better suits them,
  * write a Packed32SingleBlock implementation if necessary (I didn't do it 
 because I have no 32-bits computer to test the performance improvements).
 I think this would allow more fine-grained control over the speed/space 
 trade-off, what do you think?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information

Build failed in Jenkins: Lucene-Solr-trunk-Linux-Java7-64 #94

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java7-64/94/

--
[...truncated 11516 lines...]
clover.info:
 [echo] 
 [echo]   Clover not found. Code coverage reports disabled.
 [echo] 

clover:

common.compile-core:

compile-core:

compile-test-framework:

ivy-availability-check:

ivy-fail:

ivy-configure:

resolve:
[ivy:retrieve] :: loading settings :: url = 
jar:file:/var/lib/jenkins/.ant/lib/ivy-2.2.0.jar!/org/apache/ivy/core/settings/ivysettings.xml

init:

compile-lucene-core:

compile-core:

common.compile-test:
[mkdir] Created dir: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java7-64/checkout/solr/build/solr-solrj/classes/test
[javac] Compiling 47 source files to 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java7-64/checkout/solr/build/solr-solrj/classes/test
[javac] warning: [options] bootstrap class path not set in conjunction with 
-source 1.6
[javac] Note: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java7-64/checkout/solr/solrj/src/test/org/apache/solr/client/solrj/SolrQueryTest.java
 uses or overrides a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] Note: Some input files use unchecked or unsafe operations.
[javac] Note: Recompile with -Xlint:unchecked for details.
[javac] 1 warning

compile-test:

install-junit4-taskdef:

compile-tools:

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java7-64/checkout/lucene/ivy-settings.xml

resolve:

init:

compile-core:

validate:

common.test:
[mkdir] Created dir: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java7-64/checkout/solr/build/solr-solrj/test
   [junit4] JUnit4 says hello! Master seed: 9FD08EA239599611
   [junit4] Executing 40 suites with 2 JVMs.
   [junit4] Suite: org.apache.solr.common.util.NamedListTest
   [junit4] Completed on J0 in 0.23s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.beans.TestDocumentObjectBinder
   [junit4] Completed on J1 in 0.38s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.TestBatchUpdate
   [junit4] Completed on J1 in 4.84s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.common.params.ModifiableSolrParamsTest
   [junit4] Completed on J1 in 0.05s, 5 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.client.solrj.response.DocumentAnalysisResponseTest
   [junit4] Completed on J1 in 0.03s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.SolrExceptionTest
   [junit4] Completed on J1 in 0.02s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.common.util.TestNamedListCodec
   [junit4] Completed on J1 in 0.53s, 4 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest
   [junit4] Completed on J1 in 1.21s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest
   [junit4] Completed on J1 in 1.11s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.embedded.TestEmbeddedSolrServer
   [junit4] Completed on J1 in 0.76s, 2 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.client.solrj.embedded.SolrExampleStreamingTest
   [junit4] Completed on J0 in 15.71s, 21 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.response.TermsResponseTest
   [junit4] Completed on J0 in 0.92s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest
   [junit4] Completed on J0 in 3.08s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.response.TestSpellCheckResponse
   [junit4] Completed on J0 in 0.99s, 3 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.client.solrj.embedded.SolrExampleStreamingBinaryTest
   [junit4] Completed on J1 in 12.68s, 21 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.common.params.SolrParamTest
   [junit4] Completed on J1 in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.common.util.TestHash
   [junit4] Completed on J1 in 0.09s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.response.AnlysisResponseBaseTest
   [junit4] Completed on J1 in 0.01s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.SolrQueryTest
   [junit4] Completed on J1 in 0.04s, 9 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.embedded.MultiCoreEmbeddedTest
   [junit4] Completed on J0 in 0.49s, 1 test
   [junit4]  
   [junit4] Suite: 
org.apache.solr.client.solrj.embedded.MultiCoreExampleJettyTest
   [junit4] Completed on J0 in 1.29s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.common.util.TestJavaBinCodec
   [junit4] Completed on J0 in 0.35s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.response.FacetFieldTest
   [junit4] Completed on J1 in 0.01s, 1 test
   [junit4]

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java7-64 #90

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java7-64/90/

--
[...truncated 11836 lines...]
   [junit4] Completed in 1.65s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestPortugueseStemFilterFactory
   [junit4] Completed in 0.14s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.util.TestNumberUtils
   [junit4] Completed in 0.56s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.LeaderElectionTest
   [junit4] Completed in 33.87s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.ZkControllerTest
   [junit4] Completed in 21.62s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.TestGroupingSearch
   [junit4] Completed in 9.35s, 12 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.SpellCheckComponentTest
   [junit4] Completed in 10.67s, 9 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.TestMultiCoreConfBootstrap
   [junit4] Completed in 4.41s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestRangeQuery
   [junit4] Completed in 9.72s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.function.TestFunctionQuery
   [junit4] IGNOR/A 0.01s | TestFunctionQuery.testTotalTermFreq
   [junit4] Assumption #1: PreFlex codec does not support collection-level 
term stats
   [junit4]   2 1626 T3111 oas.SolrTestCaseJ4.setUp ###Starting 
testTotalTermFreq
   [junit4]   2 1626 T3111 oas.SolrTestCaseJ4.tearDown ###Ending 
testTotalTermFreq
   [junit4]   2
   [junit4] Completed in 2.96s, 14 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterFSTTest
   [junit4] Completed in 1.46s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSort
   [junit4] Completed in 4.47s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestFiltering
   [junit4] Completed in 5.02s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.SolrCoreTest
   [junit4] Completed in 8.14s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterTest
   [junit4] Completed in 1.93s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.IndexBasedSpellCheckerTest
   [junit4] Completed in 2.12s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.TestIndexingPerformance
   [junit4] Completed in 1.12s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestPseudoReturnFields
   [junit4] Completed in 1.90s, 13 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.DirectSolrSpellCheckerTest
   [junit4] Completed in 1.47s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.CSVRequestHandlerTest
   [junit4] Completed in 1.19s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.function.SortByFunctionTest
   [junit4] Completed in 2.53s, 2 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.update.processor.UniqFieldsUpdateProcessorFactoryTest
   [junit4] Completed in 1.03s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.XsltUpdateRequestHandlerTest
   [junit4] Completed in 1.56s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestBinaryResponseWriter
   [junit4] Completed in 2.51s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestFoldingMultitermQuery
   [junit4] Completed in 1.76s, 18 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy1
   [junit4] IGNOR/A 0.02s | TestSolrDeletionPolicy1.testCommitAge
   [junit4] Assumption #1: This test is not working on Windows (or maybe 
machines with only 2 CPUs)
   [junit4]   2 1818 T3168 oas.SolrTestCaseJ4.setUp ###Starting testCommitAge
   [junit4]   2 1830 T3168 C178 oasu.DirectUpdateHandler2.deleteAll 
[collection1] REMOVING ALL DOCUMENTS FROM INDEX
   [junit4]   2 1831 T3168 C178 UPDATE [collection1] webapp=null path=null 
params={} {deleteByQuery=*:*} 0 1
   [junit4]   2 1832 T3168 oas.SolrTestCaseJ4.tearDown ###Ending testCommitAge
   [junit4]   2
   [junit4] Completed in 1.85s, 3 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.internal.csv.CSVPrinterTest
   [junit4] Completed in 0.58s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.TestCSVLoader
   [junit4] Completed in 1.34s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.PrimitiveFieldTypeTest
   [junit4] Completed in 1.68s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestQueryUtils
   [junit4] Completed in 1.20s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.response.TestPHPSerializedResponseWriter
   [junit4] Completed in 1.64s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.DirectUpdateHandlerOptimizeTest
   [junit4] Completed in 1.61s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.AlternateDirectoryTest
   [junit4] Completed in 1.14s, 1 test
   [junit4]  
   [junit4] Suite:

[jira] [Reopened] (SOLR-3309) Slow WAR startups due to annotation scaning (affects Jetty 8)


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

James Dyer reopened SOLR-3309:
--

  Assignee: James Dyer  (was: Hoss Man)

re-opening to change the web-app / tag as discussed.



 Slow WAR startups due to annotation scaning (affects Jetty 8)
 -

 Key: SOLR-3309
 URL: https://issues.apache.org/jira/browse/SOLR-3309
 Project: Solr
  Issue Type: Bug
Reporter: Bill Bell
Assignee: James Dyer
 Fix For: 4.0

 Attachments: SOLR-3309.patch


 Need to modify web.xml to increase the speed of container startup time. The 
 header also appears to need to be modified...
 http://mostlywheat.wordpress.com/2012/03/10/speeding-up-slow-jetty-8-startups/
 http://www.javabeat.net/articles/print.php?article_id=100
 Adding 'metadata-complete=true' to our web.xml's web-app restored our 
 startup time to 8 seconds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-3309) Slow WAR startups due to annotation scaning (affects Jetty 8)


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

James Dyer updated SOLR-3309:
-

Attachment: SOLR-3309.patch

The original commit for this issue followed a misprint in the 2.5 servlet spec 
on the examples, pages 153-4 
(http://download.oracle.com/otn-pub/jcp/servlet-2.5-mrel2-eval-oth-JSpec/servlet-2_5-mrel2-spec.pdf).
  While this works on Tomcat7  Jetty8, it does not work with Jboss5 (which 
apparently is doing strict verification).  This patch follows the information 
on page 109ff of the same specification and also the xsd file at 
http://java.sun.com/xml/ns/javaee/web-app_2_5.xsd  (note:  There is no xsd file 
available at http://java.sun.com/xml/ns/j2ee/web-app_2_5.xsd).  I have tested 
this with JBoss5, Tomcat7  the Jetty8-based solr example.

I will commit shortly unless anyone disagrees.

 Slow WAR startups due to annotation scaning (affects Jetty 8)
 -

 Key: SOLR-3309
 URL: https://issues.apache.org/jira/browse/SOLR-3309
 Project: Solr
  Issue Type: Bug
Reporter: Bill Bell
Assignee: James Dyer
 Fix For: 4.0

 Attachments: SOLR-3309.patch, SOLR-3309.patch


 Need to modify web.xml to increase the speed of container startup time. The 
 header also appears to need to be modified...
 http://mostlywheat.wordpress.com/2012/03/10/speeding-up-slow-jetty-8-startups/
 http://www.javabeat.net/articles/print.php?article_id=100
 Adding 'metadata-complete=true' to our web.xml's web-app restored our 
 startup time to 8 seconds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3464) softCommit option for HttpSolrServer commit method

2012-05-22 Thread Tommaso Teofili (JIRA)


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

Tommaso Teofili commented on SOLR-3464:
---

fixed in r1341658

 softCommit option for HttpSolrServer commit method
 --

 Key: SOLR-3464
 URL: https://issues.apache.org/jira/browse/SOLR-3464
 Project: Solr
  Issue Type: Improvement
  Components: clients - java
Affects Versions: 4.0
Reporter: Marco Crivellaro
Priority: Minor

 HttpSolrServer.commit method doesn't have softCommit option which appears to
 be an option available for the commit command:
 http://wiki.apache.org/solr/UpdateXmlMessages#A.22commit.22_and_.22optimize.22

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Jenkins build is back to normal : Lucene-Solr-trunk-Windows-Java7-64 #91

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java7-64/91/changes


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

Jenkins build is back to normal : Lucene-Solr-trunk-Linux-Java7-64 #95

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java7-64/95/changes


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

[jira] [Updated] (SOLR-2822) don't run update processors twice


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

Hoss Man updated SOLR-2822:
---

Attachment: SOLR-2822.patch

updated patch to trunk.



 don't run update processors twice
 -

 Key: SOLR-2822
 URL: https://issues.apache.org/jira/browse/SOLR-2822
 Project: Solr
  Issue Type: Sub-task
  Components: SolrCloud, update
Reporter: Yonik Seeley
 Fix For: 4.0

 Attachments: SOLR-2822.patch, SOLR-2822.patch, SOLR-2822.patch


 An update will first go through processors until it gets to the point where 
 it is forwarded to the leader (or forwarded to replicas if already on the 
 leader).
 We need a way to skip over the processors that were already run (perhaps by 
 using a processor chain dedicated to sub-updates?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3215) We should clone the SolrInputDocument before adding locally and then send that clone to replicas.


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

Hoss Man commented on SOLR-3215:


bq. Cloning with the current SolrInputDocument, SolrInputField apis is a little 
scary - there is an Object to contend with - but it seems we can pretty much 
count on that being a primitive that we don't have to clone?

bq. ... currently we have to offer this (local is special) as well though - 
it's a requirement for our current 'super safe' mode that we add locally first.

Strawman suggestion: instead of using simple {{SolrInputDocument.clone()}}, 
with the scariness miller mentioned about some processor maybe creating a field 
value that isn't Clonable, what if instead we:
 # use the JavaBinCodec to serialize the SolrInputDocument to a byte[]
 # hang onto that byte[] while doing the local add
 # then (re)use that byte[] in all of the requests to the remote replicas

not sure how easy the resuse of the byte[] would be given the existing SolrJ 
API but...

 * Even if some field values aren't Clonable primatives, they have to be 
serializable using the codec or we already have a bigger bug to worry about the 
the risk of concurrent mods to the object
 * Bonus: we only pay the cost of serializing the SolrInputDocument once on the 
leader, not N times for N replicas.
 * Only downside i can think of is that the leader has to buffer the whole 
doc in memory as a byte[] instead of streaming it -- but if we assume most 
shards will have more then N replicas, the trade off seems worth it -- to me 
anyway (optimize to use more RAM and save time/cpu in serializing redundently)

 

 We should clone the SolrInputDocument before adding locally and then send 
 that clone to replicas.
 -

 Key: SOLR-3215
 URL: https://issues.apache.org/jira/browse/SOLR-3215
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-3215.patch


 If we don't do this, the behavior is a little unexpected. You cannot avoid 
 having other processors always hit documents twice unless we support using 
 multiple update chains. We have another issue open that should make this 
 better, but I'd like to do this sooner than that. We are going to have to end 
 up cloning anyway when we want to offer the ability to not wait for the local 
 add before sending to replicas.
 Cloning with the current SolrInputDocument, SolrInputField apis is a little 
 scary - there is an Object to contend with - but it seems we can pretty much 
 count on that being a primitive that we don't have to clone?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-3932) Improve load time of .tii files

2012-05-22 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-3932:


bq. Can this be ported to 3.6.1

I don't think so: it should only be bug fixes in 3.6.x series...

If we somehow did a 3.7 (which we're hoping not to: hopefully we get 4.0 alpha 
out instead) then this could be backported for that...

 Improve load time of .tii files
 ---

 Key: LUCENE-3932
 URL: https://issues.apache.org/jira/browse/LUCENE-3932
 Project: Lucene - Java
  Issue Type: Improvement
Affects Versions: 3.5
 Environment: Linux
Reporter: Sean Bridges
Assignee: Michael McCandless
 Fix For: 4.0

 Attachments: LUCENE-3932.trunk.patch, perf.csv


 We have a large 50 gig index which is optimized as one segment, with a 66 MEG 
 .tii file.  This index has no norms, and no field cache.
 It takes about 5 seconds to load this index, profiling reveals that 60% of 
 the time is spent in GrowableWriter.set(index, value), and most of time in 
 set(...) is spent resizing PackedInts.Mutatable current.
 In the constructor for TermInfosReaderIndex, you initialize the writer with 
 the line,
 {quote}GrowableWriter indexToTerms = new GrowableWriter(4, indexSize, 
 false);{quote}
 For our index using four as the bit estimate results in 27 resizes.
 The last value in indexToTerms is going to be ~ tiiFileLength, and if instead 
 you use,
 {quote}int bitEstimate = (int) Math.ceil(Math.log10(tiiFileLength) / 
 Math.log10(2));
 GrowableWriter indexToTerms = new GrowableWriter(bitEstimate, indexSize, 
 false);{quote}
 Load time improves to ~ 2 seconds.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Updated] (SOLR-2796) AddUpdateCommand.getIndexedId doesn't work with schema configured defaults/copyField - UUIDField/copyField can not be used as uniqueKey field


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

Hoss Man updated SOLR-2796:
---

Description: 
in Solr 1.4, and the HEAD of the 3x branch, the UUIDField can be used as the 
uniqueKey field even if documents do not specify a value by taking advantage of 
the {{default=NEW}} feature of UUIDField.

Similarly, a copyField can be used to populate the uniqueKey field with data 
from some field with another name -- multiple copyFields can even be used if 
there is no overlap (ie: if you have two differnet types of documents with no 
overlap in their id space, you can copy from companyId-id and from 
productId-id and use id as your uniqueKey field in solr)

Neither of these approaches work in Solr trunk because of how 
{{AddUpdateCommand.getIndexedId}} is currently used by the DirectUpdateHander2 
(see [r1152500|http://svn.apache.org/viewvc?view=revisionrevision=1152500]).

  was:in Solr 1.4, and the HEAD of the 3x branch, the UUIDField can be used as 
the uniqueKey field even if documents do not specify a value by taking 
advantage of the {{default=NEW}} feature of UUIDField.  but something has 
changed in trunk to break this behavior.

   Priority: Blocker  (was: Major)
Summary: AddUpdateCommand.getIndexedId doesn't work with schema 
configured defaults/copyField - UUIDField/copyField can not be used as 
uniqueKey field  (was: AddUpdateCommand.getIndexedId doesn't work with schema 
configured defaults - UUIDField can not be used as uniqueKey field)

Updating descriptiong after looking into it a bit more.

Even if we reverted some of the logic in {{AddUpdateCommand.getIndexedId}} to 
work the way {{DirectUpdateHandler.getIndexedId(Document)}} did in the 3x 
branch, this defered/delayed creating of the uniqueKey field just fundamentally 
can't work in SolrCloud because we have to be able to determine the value for 
the uniqueKey field well before any schema defaults/copyFields so that the 
distrib processor knows which shard to forward to.

I think we should bite the bullet and say Starting with Solr 4, schema 
defaults and copyFields can not be used to populate the uniqueKey field (we 
can even enforce this when parsing the schema - error if the uniqueKey field 
has a declared default or is the dest of a copyField) and provide 
UpdateProcessor alternatives for the behaviors that were previously possible 
with schema options...

 * FielCopyUpdateProcessor - SOLR-2599
 * UUIDFieldUpdateProcessor - generates a new UUID for a configured field name 
if it doesn't already have a value in it
 * TimestampUpdateProcessor - generates a new Date for a configured field name 
if it doesn't already have a value in it (unlikely anyone is useing a DateField 
as their uniqueKey, but it's possible and fairly easy to offer this just in 
case)

thoughts?


 AddUpdateCommand.getIndexedId doesn't work with schema configured 
 defaults/copyField - UUIDField/copyField can not be used as uniqueKey field
 -

 Key: SOLR-2796
 URL: https://issues.apache.org/jira/browse/SOLR-2796
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.0
Reporter: Hoss Man
Priority: Blocker
 Fix For: 4.0

 Attachments: SOLR-2796.patch


 in Solr 1.4, and the HEAD of the 3x branch, the UUIDField can be used as the 
 uniqueKey field even if documents do not specify a value by taking advantage 
 of the {{default=NEW}} feature of UUIDField.
 Similarly, a copyField can be used to populate the uniqueKey field with data 
 from some field with another name -- multiple copyFields can even be used if 
 there is no overlap (ie: if you have two differnet types of documents with no 
 overlap in their id space, you can copy from companyId-id and from 
 productId-id and use id as your uniqueKey field in solr)
 Neither of these approaches work in Solr trunk because of how 
 {{AddUpdateCommand.getIndexedId}} is currently used by the 
 DirectUpdateHander2 (see 
 [r1152500|http://svn.apache.org/viewvc?view=revisionrevision=1152500]).

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-4051) Fix File Headers for Lucene40 StoredFields TermVectors

2012-05-22 Thread Robert Muir (JIRA)


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

Robert Muir commented on LUCENE-4051:
-

+1 to commit, thanks for working this! Lets get this in asap. as soon as file 
formats 
changes are solidified we can start working towards a release candidate for 4.0 
alpha :)

 Fix File Headers for Lucene40 StoredFields  TermVectors
 

 Key: LUCENE-4051
 URL: https://issues.apache.org/jira/browse/LUCENE-4051
 Project: Lucene - Java
  Issue Type: Task
  Components: core/codecs
Affects Versions: 4.0
Reporter: Simon Willnauer
Assignee: Simon Willnauer
 Fix For: 4.0

 Attachments: LUCENE-4051.patch, LUCENE-4051.patch, LUCENE-4051.patch, 
 LUCENE-4051.patch, LUCENE-4051.patch


 Currently we still write the old file header format in 
 Lucene40StoredFieldFormat  Lucene40TermVectorsFormat. We should cut over to 
 use CodecUtil and reset the versioning before we release Lucene 4.0

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-2599) FieldCopy Update Processor


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

Hoss Man commented on SOLR-2599:


Jan:

I did not incorporate any sort of copy field equivalent in the SOLR-2802 work, 
but i did implement the append logic as a processor (see below)

Comments on your patch...

* my personal pref would be to use a slight diff name... (maybe 
CloneFieldUpdateProcessor ?) to help differentiate slightly from 
{{copyField/}} and reduce the likelihood of confusion during casual 
discussion in email/irc (ie: I'm copying field A to B...; wait, are you 
FieldCopy-ing or CopyField-ing?)
* as mentioned in SOLR-2825 + SOLR-3095, you shouldn't need to explicitly 
handle enabled in the individual processors
* i would eliminate the append, append.delim, and multiValued options and only 
support the multiValued=true behavior - if they want the append logic they can 
combine this processor with the ConcatFieldUpdateProcessorFactory
* instead of a move=true boolean config, i think it would be more clear what 
the behavior/alternatives are if we used an action=clone|rename config, with 
the default being clone
* instead of the simple whitespace seperated source field name config, it 
would be nice if we could reuse the field name selector syntax options from 
FieldMutatingUpdateProcessorFactory (multiple fieldName, fieldRegex, typeName, 
and typeClass as well as excludes of any/all of those)
* need to think carefully about how maxChars should work:
** what if the source values aren't Strings? they could easily be numbers or 
dates, so it seems like a bad idea to convert them to strings just because they 
are copied/renamed.
** even if all we worry about is strings, should it be maxChars per value, 
maxChars per source field, or total maxChars in dest?
*** specifics need documented
** personally: i would suggest ripping out the maxChars option and making it a 
distinct processor that can be configured later in the chain.  if we leave it 
in, then i think it's really important that it should be ignored or throw and 
error unless the value implements CharSequence, and not forcably toString() 
every copied value. (so this processor will still be useful with numeric values)
* need to think carefully about field boosts:
** either we should try to preserve/combine them on move/copy, or we should 
make sure we explicitly blow them away
** either way we need to document it
** if i'm reading the patch correctly it currently obliterates the boost on the 
dest field in all cases, even if there is not source value(s) to copy, and 
ignores any boost on any source field, but we should double check that.

 FieldCopy Update Processor
 --

 Key: SOLR-2599
 URL: https://issues.apache.org/jira/browse/SOLR-2599
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
 Fix For: 4.0

 Attachments: SOLR-2599.patch, SOLR-2599.patch


 Need an UpdateProcessor which can copy and move fields

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (SOLR-3215) We should clone the SolrInputDocument before adding locally and then send that clone to replicas.


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

Hoss Man commented on SOLR-3215:


bq. Are there use cases for this?)

FWIW: the other use case that just occurred to me today is trying to use any 
update processors that deal with multiple field values (either existing 
processors people may have written, or any of the new ones added by SOLR-2802, 
or SOLR-2599) in conjunction with field updating (SOLR-139) which is 
implemented as part of the DistributedUpdateProcessor.

ie: if you want to have a multivalued all_prices field, and a single valued 
lowest_price field that you populate using a combination of 
CloneFieldUpdateProcessorFactory + MinFieldValueUpdateProcessorFactory -- that 
will need to happen after the DistributedUpdateProcessor in order to ensure all 
the values are available if someone does field update to add a value to 
all_prices.



 We should clone the SolrInputDocument before adding locally and then send 
 that clone to replicas.
 -

 Key: SOLR-3215
 URL: https://issues.apache.org/jira/browse/SOLR-3215
 Project: Solr
  Issue Type: Improvement
Reporter: Mark Miller
Assignee: Mark Miller
 Fix For: 4.0

 Attachments: SOLR-3215.patch


 If we don't do this, the behavior is a little unexpected. You cannot avoid 
 having other processors always hit documents twice unless we support using 
 multiple update chains. We have another issue open that should make this 
 better, but I'd like to do this sooner than that. We are going to have to end 
 up cloning anyway when we want to offer the ability to not wait for the local 
 add before sending to replicas.
 Cloning with the current SolrInputDocument, SolrInputField apis is a little 
 scary - there is an Object to contend with - but it seems we can pretty much 
 count on that being a primitive that we don't have to clone?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java6-64 #158

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/158/

--
[...truncated 10316 lines...]
   [junit4] Completed in 0.09s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.util.DateMathParserTest
   [junit4] Completed in 0.19s, 8 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.QueryElevationComponentTest
   [junit4] Completed in 8.08s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.CommonGramsFilterFactoryTest
   [junit4] Completed in 0.02s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.LeaderElectionTest
   [junit4] Completed in 29.63s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.NodeStateWatcherTest
   [junit4] Completed in 35.59s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.TestReplicationHandler
   [junit4] Completed in 47.41s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestPhoneticFilterFactory
   [junit4] Completed in 11.72s, 5 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedSpellCheckComponentTest
   [junit4] Completed in 17.89s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.BasicZkTest
   [junit4] Completed in 7.12s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.TestJoin
   [junit4] Completed in 17.58s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestFaceting
   [junit4] Completed in 20.51s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.SpellCheckComponentTest
   [junit4] Completed in 6.15s, 9 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedQueryElevationComponentTest
   [junit4] Completed in 5.35s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterFSTTest
   [junit4] Completed in 1.77s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.BasicFunctionalityTest
   [junit4] IGNORED 0.00s | BasicFunctionalityTest.testDeepPaging
   [junit4] Cause: Annotated @Ignore(See SOLR-1726)
   [junit4] Completed in 3.67s, 23 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.IndexBasedSpellCheckerTest
   [junit4] Completed in 1.72s, 5 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.search.similarities.TestLMDirichletSimilarityFactory
   [junit4] Completed in 0.21s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.TermsComponentTest
   [junit4] Completed in 1.61s, 13 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.admin.ShowFileRequestHandlerTest
   [junit4] Completed in 1.58s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.highlight.HighlighterTest
   [junit4] Completed in 3.45s, 27 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.function.SortByFunctionTest
   [junit4] Completed in 3.57s, 2 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.update.processor.UniqFieldsUpdateProcessorFactoryTest
   [junit4] Completed in 1.16s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestPropInject
   [junit4] Completed in 2.22s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.CurrencyFieldTest
   [junit4] IGNORED 0.00s | CurrencyFieldTest.testPerformance
   [junit4] Cause: Annotated @Ignore()
   [junit4] Completed in 1.62s, 8 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.TestOmitPositions
   [junit4] Completed in 1.24s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy1
   [junit4] IGNOR/A 0.02s | TestSolrDeletionPolicy1.testCommitAge
   [junit4] Assumption #1: This test is not working on Windows (or maybe 
machines with only 2 CPUs)
   [junit4]   2 1308 T3302 oas.SolrTestCaseJ4.setUp ###Starting testCommitAge
   [junit4]   2 1313 T3302 C212 oasu.DirectUpdateHandler2.deleteAll 
[collection1] REMOVING ALL DOCUMENTS FROM INDEX
   [junit4]   2 1314 T3302 C212 UPDATE [collection1] webapp=null path=null 
params={} {deleteByQuery=*:*} 0 1
   [junit4]   2 1315 T3302 oas.SolrTestCaseJ4.tearDown ###Ending testCommitAge
   [junit4]   2
   [junit4] Completed in 1.34s, 3 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.core.RequestHandlersTest
   [junit4] Completed in 1.16s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.TestCSVLoader
   [junit4] Completed in 1.42s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.DebugComponentTest
   [junit4] Completed in 1.31s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.FileBasedSpellCheckerTest
   [junit4] Completed in 1.18s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestValueSourceCache
   [junit4] Completed in 1.06s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.BadComponentTest
   [junit4] Completed in 0.95s, 1 test
   [junit4]  
   [junit4] Suite:

[jira] [Updated] (LUCENE-4072) CharFilter that Unicode-normalizes input

2012-05-22 Thread Ippei UKAI (JIRA)


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

Ippei UKAI updated LUCENE-4072:
---

Attachment: ippeiukai-ICUNormalizer2CharFilter-4752cad.zip

 CharFilter that Unicode-normalizes input
 

 Key: LUCENE-4072
 URL: https://issues.apache.org/jira/browse/LUCENE-4072
 Project: Lucene - Java
  Issue Type: New Feature
  Components: modules/analysis
Reporter: Ippei UKAI
 Attachments: ippeiukai-ICUNormalizer2CharFilter-4752cad.zip


 I'd like to contribute a CharFilter that Unicode-normalizes input with ICU4J.
 The benefit of having this process as CharFilter is that tokenizer can work 
 on normalised text while offset-correction ensuring fast vector highlighter 
 and other offset-dependent features do not break.
 The implementation is available at following repository:
 https://github.com/ippeiukai/ICUNormalizer2CharFilter
 Unfortunately this is my unpaid side-project and cannot spend much time to 
 merge my work to Lucene to make appropriate patch. I'd appreciate it if 
 anyone could give it a go. I'm happy to relicense it to whatever that meets 
 your needs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

[jira] [Commented] (LUCENE-4072) CharFilter that Unicode-normalizes input

2012-05-22 Thread Ippei UKAI (JIRA)


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

Ippei UKAI commented on LUCENE-4072:


Robert,
The zipped copy of the repository is attached and licensed to ASF for inclusion.
Thanks!

 CharFilter that Unicode-normalizes input
 

 Key: LUCENE-4072
 URL: https://issues.apache.org/jira/browse/LUCENE-4072
 Project: Lucene - Java
  Issue Type: New Feature
  Components: modules/analysis
Reporter: Ippei UKAI
 Attachments: ippeiukai-ICUNormalizer2CharFilter-4752cad.zip


 I'd like to contribute a CharFilter that Unicode-normalizes input with ICU4J.
 The benefit of having this process as CharFilter is that tokenizer can work 
 on normalised text while offset-correction ensuring fast vector highlighter 
 and other offset-dependent features do not break.
 The implementation is available at following repository:
 https://github.com/ippeiukai/ICUNormalizer2CharFilter
 Unfortunately this is my unpaid side-project and cannot spend much time to 
 merge my work to Lucene to make appropriate patch. I'd appreciate it if 
 anyone could give it a go. I'm happy to relicense it to whatever that meets 
 your needs.

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Jenkins build is back to normal : Lucene-Solr-trunk-Windows-Java6-64 #159

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/159/


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

[jira] [Commented] (SOLR-3432) deleteByQuery silently ignored if updateLog is enabled, but {{_version_}} field does not exist in schema

2012-05-22 Thread Lance Norskog (JIRA)


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

Lance Norskog commented on SOLR-3432:
-

bq. we might consider adding to the IndexSchema automagically on startup if it 
isn't explicitly declared in schema.xml
Please don't do automagic things. They can cover up real errors, which then 
become hell to find.

Just state clearly in the exception what is wrong. Fail Loud.

 deleteByQuery silently ignored if updateLog is enabled, but {{_version_}} 
 field does not exist in schema 
 -

 Key: SOLR-3432
 URL: https://issues.apache.org/jira/browse/SOLR-3432
 Project: Solr
  Issue Type: Bug
 Environment: Tomcat 7
Reporter: David
Assignee: Yonik Seeley
Priority: Blocker
 Fix For: 4.0

 Attachments: SOLR-3432.test.patch, schema.xml, solr.xml, 
 solrconfig.xml, web.xml


 deleteByQuery is silently ignored if there the updateLog is configurd in 
 solrconfig.xml, but there is no {{\_version\_}} field in the schema.xml (ie: 
 if someone copies the example configs, and then prunes down the schema to 
 remove fields they don't think they need/want)
 To reproduce:
 * comment out {{\_version\_}} in example schema
 * {{java -jar start.jar}}
 * {{java -Ddata=args -jar post.jar 'adddocfield 
 name=idHOSS/field/doc/add'}}
 * {{java -Ddata=args -jar post.jar 'deletequeryid:HOSS/query/delete'}}
 ** or: {{java -Ddata=args -jar post.jar 
 'deletequery\*:\*/query/delete'}}
 Note in the logs that SolrCore logs the deleteByQuery, but there is no log of 
 it executing...
 {noformat}
 May 3, 2012 4:36:24 PM org.apache.solr.update.processor.LogUpdateProcessor 
 finish
 INFO: [collection1] webapp=/solr path=/update params={} {deleteByQuery=*:*} 0 
 41
 {noformat}
 Workarround: add this ield to your schema.xml...
 {code}
field name=_version_ type=long indexed=true stored=true/
 {code}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators: 
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira



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

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java7-64 #93

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java7-64/93/

--
[...truncated 11685 lines...]
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestHTMLStripCharFilterFactory
   [junit4] Completed in 0.02s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSearchPerf
   [junit4] Completed in 0.51s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestGalicianMinimalStemFilterFactory
   [junit4] Completed in 0.02s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterWFSTTest
   [junit4] Completed in 1.79s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.EchoParamsTest
   [junit4] Completed in 0.18s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestRealTimeGet
   [junit4] IGNOR/A 0.01s | TestRealTimeGet.testStressRecovery
   [junit4] Assumption #1: FIXME: This test is horribly slow sometimes on 
Windows!
   [junit4] Completed in 12.74s, 8 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.OverseerTest
   [junit4] Completed in 54.89s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.BasicDistributedZkTest
   [junit4] Completed in 68.39s, 1 test
   [junit4]  
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedSpellCheckComponentTest
   [junit4] Completed in 14.27s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.BasicZkTest
   [junit4] Completed in 6.24s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.TestJoin
   [junit4] Completed in 8.61s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestFaceting
   [junit4] Completed in 13.09s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.QueryElevationComponentTest
   [junit4] Completed in 6.77s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.DirectUpdateHandlerTest
   [junit4] Completed in 4.73s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestRangeQuery
   [junit4] Completed in 9.60s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterFSTTest
   [junit4] Completed in 2.09s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestJmxIntegration
   [junit4] IGNORED 0.00s | TestJmxIntegration.testJmxOnCoreReload
   [junit4] Cause: Annotated @Ignore(timing problem? 
https://issues.apache.org/jira/browse/SOLR-2715)
   [junit4] Completed in 2.90s, 3 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.SolrInfoMBeanTest
   [junit4] Completed in 1.37s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestWriterPerf
   [junit4] Completed in 1.54s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSurroundQueryParser
   [junit4] Completed in 1.19s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.CSVRequestHandlerTest
   [junit4] Completed in 1.19s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestWordDelimiterFilterFactory
   [junit4] Completed in 1.84s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.SpatialFilterTest
   [junit4] Completed in 2.37s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.DocumentAnalysisRequestHandlerTest
   [junit4] Completed in 1.60s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestDocSet
   [junit4] Completed in 1.18s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.response.TestPHPSerializedResponseWriter
   [junit4] Completed in 1.36s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.BadComponentTest
   [junit4] Completed in 1.08s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.util.SolrPluginUtilsTest
   [junit4] Completed in 1.35s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestExtendedDismaxParser
   [junit4] Completed in 13.35s, 8 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestArbitraryIndexDir
   [junit4] Completed in 1.39s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSolrQueryParser
   [junit4] Completed in 1.57s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.TermVectorComponentTest
   [junit4] Completed in 1.94s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestQuerySenderListener
   [junit4] Completed in 1.36s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestMergePolicyConfig
   [junit4] Completed in 1.09s, 1 test
   [junit4]  
   [junit4] Suite: 
org.apache.solr.analysis.TestJapanesePartOfSpeechStopFilterFactory
   [junit4] Completed in 0.02s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.OutputWriterTest
   [junit4] Completed in 0.46s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.TestSolrCoreProperties
   [junit4] Completed in 0.39s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.MinimalSchemaTest
   [junit4] Completed in 0.61s, 3 tests
   [junit4]

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java6-64 #161

See 
http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows-Java6-64/161/

--
[...truncated 10314 lines...]
   [junit4]  
   [junit4] Suite: org.apache.solr.util.PrimUtilsTest
   [junit4] Completed in 0.08s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestRussianFilters
   [junit4] Completed in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestCzechStemFilterFactory
   [junit4] Completed in 0.02s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestBrazilianStemFilterFactory
   [junit4] Completed in 0.03s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestMergePolicyConfig
   [junit4] Completed in 1.69s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.ZkSolrClientTest
   [junit4] Completed in 23.14s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestPhoneticFilterFactory
   [junit4] Completed in 15.33s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestRecovery
   [junit4] Completed in 16.48s, 9 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.BasicZkTest
   [junit4] Completed in 10.20s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.update.AutoCommitTest
   [junit4] Completed in 9.36s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestFaceting
   [junit4] Completed in 18.34s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.DirectUpdateHandlerTest
   [junit4] Completed in 4.43s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.ConvertedLegacyTest
   [junit4] Completed in 5.42s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.SolrCoreTest
   [junit4] Completed in 6.98s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.BadIndexSchemaTest
   [junit4] Completed in 1.65s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestJmxIntegration
   [junit4] IGNORED 0.00s | TestJmxIntegration.testJmxOnCoreReload
   [junit4] Cause: Annotated @Ignore(timing problem? 
https://issues.apache.org/jira/browse/SOLR-2715)
   [junit4] Completed in 2.41s, 3 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.BasicFunctionalityTest
   [junit4] IGNORED 0.00s | BasicFunctionalityTest.testDeepPaging
   [junit4] Cause: Annotated @Ignore(See SOLR-1726)
   [junit4] Completed in 4.22s, 23 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.SolrInfoMBeanTest
   [junit4] Completed in 1.41s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.admin.LukeRequestHandlerTest
   [junit4] Completed in 4.23s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestCoreContainer
   [junit4] Completed in 5.13s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSurroundQueryParser
   [junit4] Completed in 2.11s, 1 test
   [junit4]  
   [junit4] Suite: 
org.apache.solr.update.processor.UniqFieldsUpdateProcessorFactoryTest
   [junit4] Completed in 1.82s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestWordDelimiterFilterFactory
   [junit4] Completed in 2.24s, 7 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.DocumentBuilderTest
   [junit4] Completed in 1.46s, 11 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestRemoteStreaming
   [junit4] Completed in 2.08s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestBinaryResponseWriter
   [junit4] Completed in 3.11s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.DocumentAnalysisRequestHandlerTest
   [junit4] Completed in 1.78s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.servlet.CacheHeaderTest
   [junit4] Completed in 2.04s, 5 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.update.processor.FieldMutatingUpdateProcessorTest
   [junit4] Completed in 1.84s, 20 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestQueryTypes
   [junit4] Completed in 1.93s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestReversedWildcardFilterFactory
   [junit4] Completed in 1.28s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.TestCSVLoader
   [junit4] Completed in 2.23s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.DebugComponentTest
   [junit4] Completed in 1.79s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.IndexReaderFactoryTest
   [junit4] Completed in 1.29s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestExtendedDismaxParser
   [junit4] Completed in 11.95s, 8 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.FieldAnalysisRequestHandlerTest
   [junit4] Completed in 1.22s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestPropInjectDefaults
   [junit4] Completed in 1.09s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.UpdateParamsTest
   [junit4] Completed in 1.31s, 1 test
   [junit4]  
   [junit4]

Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java7-64 #94