date:20120524

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

--
[...truncated 13653 lines...]
   [junit4]   2at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
   [junit4]   2at java.lang.reflect.Method.invoke(Method.java:597)
   [junit4]   2at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
   [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 449 T80 C12 REQ [collection1] webapp=null path=null

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

2012-05-24 Thread Uwe Schindler

No virus scanners active, but Windows Search in this VM.

-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de


 -Original Message-
 From: ysee...@gmail.com [mailto:ysee...@gmail.com] On Behalf Of Yonik
 Seeley
 Sent: Thursday, May 24, 2012 7:06 AM
 To: dev@lucene.apache.org
 Subject: Re: Build failed in Jenkins: Lucene-Solr-trunk-Windows-Java6-64
#175
 
 On Thu, May 24, 2012 at 12:50 AM, Mark Miller markrmil...@gmail.com
 wrote:
  As far as I can tell, this appears to perhaps be a windows issue with
 replication - if the logged errors are involved, it's not finding a file
to copy that
 it's expecting to find. Search me as to why. Certainly seems to be finding
them
 on the linux and freebsd runs.
 
 It's unable to move, followed by unable to copy because The system cannot
 find the path specified.
 Windows has the extra issue of not being able to move a file that is open
for
 any reason, so I imagine one would never get to the copy logic in UNIX
 environments?
 
 Even some virus scanners have caused tests (and sometimes even svn) to
fail on
 windows, so hopefully it's nothing like that.
 We should prob add extra logging when both the move and copy fail to try
and
 pin down exactly why.
 
 -Yonik
 http://lucidimagination.com
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
 commands, e-mail: dev-h...@lucene.apache.org


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

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

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


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

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

2012-05-24 Thread Mikhail Khludnev (JIRA)


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

Mikhail Khludnev commented on SOLR-2694:


Ethan,

# that patch (dated 1/1/12) has absolutely no sense, I tell you as an author: 
UpdateProcessors are thread unaware prototypes, not singletons;
# the later patch from SOLR-2804 make sense for DIH with threads, which is 
not supported further;
# your core problem is The update chain we defined is enforced with 
singleton, I suggest instantiate the necessary logic in UpdateProcessorFactory 
and provide it for concurrent access from thread unaware UpdateProcessors. 


 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

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

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

1 tests failed.
REGRESSION:  
org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeDelete

Error Message:
searcher529 wasn't soon enough after soft529: 1337846458168 ! 1337846458022 + 
100 (fudge)

Stack Trace:
java.lang.AssertionError: searcher529 wasn't soon enough after soft529: 
1337846458168 ! 1337846458022 + 100 (fudge)
at 
__randomizedtesting.SeedInfo.seed([928E591D9B7B5D0B:55C2E18080D390BB]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at 
org.apache.solr.update.SoftAutoCommitTest.testSoftAndHardCommitMaxTimeDelete(SoftAutoCommitTest.java:254)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1969)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:814)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:875)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:889)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:821)
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 
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 10460 lines...]



-
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 #180

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

--
[...truncated 10544 lines...]
   [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 546 T3284 oas.SolrTestCaseJ4.tearDown ###Ending testRebuild
   [junit4]   2 NOTE: reproduce with: ant test -Dtestcase=SuggesterFSTTest 
-Dtests.method=testRebuild -Dtests.seed=15890B36591C5287 -Dtests.locale=hu 
-Dtests.timezone=Asia/Tashkent -Dargs=-Dfile.encoding=Cp1252
   [junit4]   2
   [junit4] (@AfterClass output)
   [junit4]   2 3206 T3284 oas.SolrTestCaseJ4.deleteCore ###deleteCore
   [junit4]   2 3208 T3284 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=1676564635
   [junit4]   2 3208 T3284 oasc.SolrCore.close [collection1]  CLOSING SolrCore 
org.apache.solr.core.SolrCore@40a1c72e
   [junit4]   2 3209 T3284 oasc.SolrCore.closeSearcher [collection1] Closing 
main searcher on request.
   [junit4]   2 3209 T3284 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=0,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
   [junit4]   2 NOTE: test params are: codec=Lucene40, 
sim=RandomSimilarityProvider(queryNorm=true,coord=false): {}, locale=hu, 
timezone=Asia/Tashkent
   [junit4]   2 NOTE: Windows 7 6.1 amd64/Sun Microsystems Inc. 1.6.0_32 
(64-bit)/cpus=2,threads=1,free=129510952,total=245301248
   [junit4]   2 NOTE: All tests run in this JVM: [NotRequiredUniqueKeyTest, 
OpenExchangeRatesOrgProviderTest, MBeansHandlerTest, TestChineseFilterFactory, 
TestShingleFilterFactory, TestTurkishLowerCaseFilterFactory, LengthFilterTest, 
TestReversedWildcardFilterFactory, TestCollationKeyFilterFactory, 
NodeStateWatcherTest, TestDFRSimilarityFactory, TestSolrXMLSerializer, 
TestGreekStemFilterFactory, TestGalicianStemFilterFactory, 
IndexSchemaRuntimeFieldTest, XsltUpdateRequestHandlerTest, 
TestPhraseSuggestions, UniqFieldsUpdateProcessorFactoryTest, 
TestGreekLowerCaseFilterFactory, NumericFieldsTest,

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

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

--
[...truncated 23723 lines...]
  [jar] Building jar: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build/sandbox/lucene-sandbox-4.0-SNAPSHOT-javadoc.jar
 [echo] Building spatial...

check-queries-javadocs-uptodate:

javadocs-queries:

check-queries-uptodate:

jar-queries:

ivy-availability-check:

ivy-fail:

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

resolve:

common.init:

compile-lucene-core:

jflex-uptodate-check:

jflex-notice:

javacc-uptodate-check:

javacc-notice:

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:

clover.setup:

clover.info:
 [echo] 
 [echo]   Clover not found. Code coverage reports disabled.
 [echo] 

clover:

common.compile-core:
[javac] Compiling 1 source file to 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build/core/classes/java

compile-core:

init:

clover.setup:

clover.info:
 [echo] 
 [echo]   Clover not found. Code coverage reports disabled.
 [echo] 

clover:

common.compile-core:

compile-core:

javadocs:
[mkdir] Created dir: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build/docs/spatial
 [echo] Building spatial...

download-java6-javadoc-packagelist:
 [copy] Copying 1 file to 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build/docs/spatial
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.spatial...
  [javadoc] Loading source files for package org.apache.lucene.spatial.prefix...
  [javadoc] Loading source files for package 
org.apache.lucene.spatial.prefix.tree...
  [javadoc] Loading source files for package org.apache.lucene.spatial.util...
  [javadoc] Loading source files for package org.apache.lucene.spatial.vector...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.6.0_32
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages and classes...
  [javadoc] Building index for all classes...
  [javadoc] Generating 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build/docs/spatial/stylesheet.css...
  [javadoc] Note: Custom tags that were not seen:  @lucene.internal, 
@lucene.experimental
  [jar] Building jar: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build/spatial/lucene-spatial-4.0-SNAPSHOT-javadoc.jar
 [echo] Building suggest...

ivy-availability-check:

ivy-fail:

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

resolve:

common.init:

compile-lucene-core:

jflex-uptodate-check:

jflex-notice:

javacc-uptodate-check:

javacc-notice:

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:

clover.setup:

clover.info:
 [echo] 
 [echo]   Clover not found. Code coverage reports disabled.
 [echo] 

clover:

common.compile-core:
[javac] Compiling 1 source file to 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build/core/classes/java

compile-core:

init:

clover.setup:

clover.info:
 [echo] 
 [echo]   Clover not found. Code coverage reports disabled.
 [echo] 

clover:

compile-core:

check-lucene-core-javadocs-uptodate:

javadocs-lucene-core:

javadocs:
[mkdir] Created dir: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build/docs/suggest
 [echo] Building suggest...

download-java6-javadoc-packagelist:
 [copy] Copying 1 file to 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/lucene/build/docs/suggest
  [javadoc] Generating Javadoc
  [javadoc] Javadoc execution
  [javadoc] Loading source files for package org.apache.lucene.search.spell...
  [javadoc] Loading source files for package org.apache.lucene.search.suggest...
  [javadoc] Loading source files for package 
org.apache.lucene.search.suggest.fst...
  [javadoc] Loading source files for package 
org.apache.lucene.search.suggest.jaspell...
  [javadoc] Loading source files for package 
org.apache.lucene.search.suggest.tst...
  [javadoc] Constructing Javadoc information...
  [javadoc] Standard Doclet version 1.6.0_32
  [javadoc] Building tree for all the packages and classes...
  [javadoc] Building index for all the packages

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

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

--
[...truncated 14547 lines...]
   [junit4]   2 38804 T2812 oas.SolrTestCaseJ4.tearDown ###Ending test
   [junit4]   2 NOTE: reproduce with: ant test 
-Dtestcase=TestReplicationHandler -Dtests.method=test 
-Dtests.seed=50A98F263A2CEB7 -Dtests.locale=ar_SY 
-Dtests.timezone=Europe/Berlin -Dargs=-Dfile.encoding=Cp1252
   [junit4]   2
   [junit4] (@AfterClass output)
   [junit4]   2 38836 T2812 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=2103668511
   [junit4]   2 38837 T2812 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@4d44c983
   [junit4]   2 38837 T2812 oasc.SolrCore.closeSearcher [collection1] Closing 
main searcher on request.
   [junit4]   2 38838 T2812 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=4,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=997,cumulative_deletesById=0,cumulative_deletesByQuery=2,cumulative_errors=0}
   [junit4]   2 38841 T2812 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
   [junit4]   2 38900 T2812 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=869250023
   [junit4]   2 38900 T2812 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@6b95faa1
   [junit4]   2 38900 T2812 oasc.SolrCore.closeSearcher [collection1] Closing 
main searcher on request.
   [junit4]   2 38901 T2812 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=8,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=5,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
   [junit4]   2 38903 T2812 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
   [junit4]   2 38977 T2812 oas.SolrTestCaseJ4.deleteCore ###deleteCore
   [junit4]   2 NOTE: test params are: codec=Lucene40, 
sim=RandomSimilarityProvider(queryNorm=true,coord=true): {}, locale=ar_SY, 
timezone=Europe/Berlin
   [junit4]   2 NOTE: Windows 7 6.1 amd64/Oracle Corporation 1.7.0_04 
(64-bit)/cpus=2,threads=2,free=130337472,total=275120128
   [junit4]   2 NOTE: All tests run in this JVM: [BasicDistributedZkTest, 
TestRangeQuery, BasicZkTest, RAMDirectoryFactoryTest, QueryParsingTest, 
BadComponentTest, PolyFieldTest, CommonGramsQueryFilterFactoryTest, 
ShowFileRequestHandlerTest, LeaderElectionTest, CurrencyFieldTest, 
TestUAX29URLEmailTokenizerFactory, TestHindiFilters, PluginInfoTest, 
DisMaxRequestHandlerTest, TestFrenchLightStemFilterFactory, 
SpellingQueryConverterTest, TestLMDirichletSimilarityFactory, 
TestMultiCoreConfBootstrap, TestQuerySenderNoQuery, 
TestDictionaryCompoundWordTokenFilterFactory, RequiredFieldsTest, 
FileBasedSpellCheckerTest, TestDelimitedPayloadTokenFilterFactory, 
AlternateDirectoryTest, TestBinaryField, TestSolrDeletionPolicy2, 
TestKeywordMarkerFilterFactory, TermVectorComponentTest, CloudStateUpdateTest, 
TestSolrXMLSerializer, MoreLikeThisHandlerTest, DateMathParserTest, 
SoftAutoCommitTest, TestGreekStemFilterFactory, TestSynonymFilterFactory, 
LoggingHandlerTest, TestPhraseSuggestions, SortByFunctionTest, 
TestPatternTokenizerFactory, TestExtendedDismaxParser, 
TestMappingCharFilterFactory, HighlighterTest, TestLatvianStemFilterFactory, 
SpellCheckCollatorTest, TestNGramFilters, TestJoin, 
SpellPossibilityIteratorTest, DocumentBuilderTest, TestFiltering, 
TestSuggestSpellingConverter, TestDFRSimilarityFactory, 
TestJapaneseTokenizerFactory, TestPHPSerializedResponseWriter, JSONWriterTest, 
TestGermanLightStemFilterFactory, UpdateRequestProcessorFactoryTest, 
TestFastLRUCache, TestRealTimeGet, DirectUpdateHandlerOptimizeTest, 
NotRequiredUniqueKeyTest, TestTurkishLowerCaseFilterFactory, 
OpenExchangeRatesOrgProviderTest, TestCoreContainer, TestCSVResponseWriter, 
TestUpdate, DirectSolrConnectionTest, TestMultiWordSynonyms, 
XsltUpdateRequestHandlerTest, MultiTermTest, NodeStateWatcherTest, 
TestDistributedSearch, SolrCoreCheckLockOnStartupTest, TestRandomFaceting, 
SuggesterTSTTest, TestArabicFilters, LeaderElectionIntegrationTest, 
DistributedSpellCheckComponentTest, SolrInfoMBeanTest, SolrCoreTest, 
QueryElevationComponentTest, TestFunctionQuery, 
TestGermanMinimalStemFilterFactory, TestPatternReplaceCharFilterFactory, 
TestMergePolicyConfig, ZkSolrClientTest, TestIndexSearcher, 
TestEnglishMinimalStemFilterFactory, LengthFilterTest, IndexSchemaTest, 
CloudStateTest, URLClassifyProcessorTest, DistributedTermsComponentTest, 
TestElisionFilterFactory, CSVRequestHandlerTest, TestWikipediaTokenizerFactory, 
TestSystemIdResolver, TestGreekLowerCaseFilterFactory, 
BinaryUpdateRequestHandlerTest, CacheHeaderTest, TestGermanStemFilterFactory,

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

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


-
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 #181

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


-
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 #521

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

--
[...truncated 10804 lines...]
   [junit4]   2 20389 T236 oasc.RequestHandlers.initHandlersFromConfig created 
/admin/: org.apache.solr.handler.admin.AdminHandlers
   [junit4]   2 20389 T236 oasc.RequestHandlers.initHandlersFromConfig created 
/admin/ping: solr.PingRequestHandler
   [junit4]   2 20390 T236 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
   [junit4]   2 20393 T236 oass.SolrIndexSearcher.init Opening 
Searcher@fdfacc4 main
   [junit4]   2 20394 T236 oass.SolrIndexSearcher.init WARNING WARNING: 
Directory impl does not support setting indexDir: 
org.apache.lucene.store.RAMDirectory
   [junit4]   2 20394 T236 oasu.CommitTracker.init Hard AutoCommit: disabled
   [junit4]   2 20395 T236 oasu.CommitTracker.init Soft AutoCommit: disabled
   [junit4]   2 20395 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
socketTimeout to: 0
   [junit4]   2 20395 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
urlScheme to: http://
   [junit4]   2 20396 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
connTimeout to: 0
   [junit4]   2 20396 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
maxConnectionsPerHost to: 20
   [junit4]   2 20396 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
corePoolSize to: 0
   [junit4]   2 20397 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
maximumPoolSize to: 2147483647
   [junit4]   2 20397 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
maxThreadIdleTime to: 5
   [junit4]   2 20397 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
sizeOfQueue to: -1
   [junit4]   2 20398 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
fairnessPolicy to: false
   [junit4]   2 20402 T237 oasc.SolrCore.registerSearcher [collection1] 
Registered new searcher Searcher@fdfacc4 
main{StandardDirectoryReader(segments_1:1)}
   [junit4]   2 20402 T236 oasc.CoreContainer.register registering core: 
collection1
   [junit4]   2 20403 T236 oasu.AbstractSolrTestCase.setUp SETUP_END 
testMultiCore
   [junit4]   2 20404 T236 oascs.MultiCoreExampleTestBase.setUp 
CORES=org.apache.solr.util.TestHarness$Initializer$1@7e6ab533 : [collection1]
   [junit4]   2 20405 T236 oejs.Server.doStart jetty-8.1.2.v20120308
   [junit4]   2 20407 T236 oejs.AbstractConnector.doStart Started 
SocketConnector@0.0.0.0:35092
   [junit4]   2 20408 T236 oasc.SolrResourceLoader.locateSolrHome JNDI not 
configured for solr (NoInitialContextEx)
   [junit4]   2 20408 T236 oasc.SolrResourceLoader.locateSolrHome using system 
property solr.solr.home: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/solr/example/multicore
   [junit4]   2 20408 T236 oasc.SolrResourceLoader.init new 
SolrResourceLoader for deduced Solr Home: 
'/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/solr/example/multicore/'
   [junit4]   2 20414 T236 oass.SolrDispatchFilter.init 
SolrDispatchFilter.init()
   [junit4]   2 20414 T236 oasc.SolrResourceLoader.locateSolrHome JNDI not 
configured for solr (NoInitialContextEx)
   [junit4]   2 20415 T236 oasc.SolrResourceLoader.locateSolrHome using system 
property solr.solr.home: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/solr/example/multicore
   [junit4]   2 20415 T236 oasc.CoreContainer$Initializer.initialize looking 
for solr.xml: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/solr/example/multicore/solr.xml
   [junit4]   2 20415 T236 oasc.CoreContainer.init New CoreContainer 
525453728
   [junit4]   2 20416 T236 oasc.CoreContainer.load Loading CoreContainer using 
Solr Home: 
'/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/solr/example/multicore/'
   [junit4]   2 20416 T236 oasc.SolrResourceLoader.init new 
SolrResourceLoader for directory: 
'/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/solr/example/multicore/'
   [junit4]   2 20425 T236 oasc.CoreContainer.load Registering Log Listener
   [junit4]   2 20438 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
socketTimeout to: 0
   [junit4]   2 20439 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
urlScheme to: http://
   [junit4]   2 20439 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
connTimeout to: 0
   [junit4]   2 20439 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
maxConnectionsPerHost to: 20
   [junit4]   2 20439 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
corePoolSize to: 0
   [junit4]   2 20440 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
maximumPoolSize to: 2147483647
   [junit4]   2 20440 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
maxThreadIdleTime to: 5
   [junit4]   2 20440 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
sizeOfQueue to: -1
   [junit4]   2 20440 T236 oashc.HttpShardHandlerFactory.getParameter Setting 
fairnessPolicy to:

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

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


-
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 #109

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


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

[jira] [Updated] (SOLR-1833) ShowFileRequestHandle should allow you to specify which files can be viewed, not just which cannot be viewed


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

Raphaël Droz updated SOLR-1833:
---

Attachment: SOLR-1833-ShowFileRequestHandler-whitelist.patch

This patch may do the trick.
Still unsure about invariants.getParams() return value (could it be an empty 
Set ?).

Whitelisting takes precedence thus overrules any hidden invariant. I think 
this is a relatively safe behavior.


 ShowFileRequestHandle should allow you to specify which files can be viewed, 
 not just which cannot be viewed
 

 Key: SOLR-1833
 URL: https://issues.apache.org/jira/browse/SOLR-1833
 Project: Solr
  Issue Type: Improvement
Affects Versions: 1.4
Reporter: Mark Miller
Priority: Minor
 Fix For: 4.1

 Attachments: SOLR-1833-ShowFileRequestHandler-whitelist.patch


 In many cases I wouldn't want to come up with every file I want hidden - 
 especially when new files may be added in the future - often you would want 
 to explicitly say which files can be viewed - this is how the old 
 gettableFiles used to work.

--
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-24 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

New patch. I added a VInt flag to the streams generated by writers so that the 
readers can know how to parse the stream. All tests passed.

 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, 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 on JIRA, see: http://www.atlassian.com/software/jira

SOLR-2923

2012-05-24 Thread Adrien Grand

Hi,

Could someone review SOLR-2923 [1]? Although the patch is a little
old, the bug still exists in trunk and the patch applies correctly.

Thank you!

1. https://issues.apache.org/jira/browse/SOLR-2923

-- 
Adrien

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

[jira] [Created] (SOLR-3485) Make /browse (files and handlers) dependencies self URL-contained

Raphaël Droz created SOLR-3485:
--

 Summary: Make /browse (files and handlers) dependencies self 
URL-contained
 Key: SOLR-3485
 URL: https://issues.apache.org/jira/browse/SOLR-3485
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0
Reporter: Raphaël Droz
Priority: Minor


Assuming that /browse may be, now or later, safe for a public use it would be 
very useful to make it self-contained in a given URL pattern in order to 
allow URL-based access restrictions.

There are 3 issues here :
* static files (css/js/img)
* external handlers like /terms, /clustering
* pattern switch between /browse/* and /collection1/browse/*

I only try to address the 1st issue, in the comment below.
If both /terms and /clustering are safe to be public, then issue 2 may be 
omitted.


--
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-2878) Allow Scorer to expose positions and payloads aka. nuke spans


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

Alan Woodward updated LUCENE-2878:
--

Attachment: LUCENE-2878.patch

Patch changing the Scorer#positions() signature to 
Scorer#positions(needsPayloads, needsOffsets), and implementing the payload 
passing functionality.  All Span payload tests now pass.

 Allow Scorer to expose positions and payloads aka. nuke spans 
 --

 Key: LUCENE-2878
 URL: https://issues.apache.org/jira/browse/LUCENE-2878
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/search
Affects Versions: Positions Branch
Reporter: Simon Willnauer
Assignee: Simon Willnauer
  Labels: gsoc2011, gsoc2012, lucene-gsoc-11, lucene-gsoc-12, 
 mentor
 Fix For: Positions Branch

 Attachments: LUCENE-2878-OR.patch, LUCENE-2878.patch, 
 LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
 LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
 LUCENE-2878_trunk.patch, LUCENE-2878_trunk.patch, PosHighlighter.patch, 
 PosHighlighter.patch


 Currently we have two somewhat separate types of queries, the one which can 
 make use of positions (mainly spans) and payloads (spans). Yet Span*Query 
 doesn't really do scoring comparable to what other queries do and at the end 
 of the day they are duplicating lot of code all over lucene. Span*Queries are 
 also limited to other Span*Query instances such that you can not use a 
 TermQuery or a BooleanQuery with SpanNear or anthing like that. 
 Beside of the Span*Query limitation other queries lacking a quiet interesting 
 feature since they can not score based on term proximity since scores doesn't 
 expose any positional information. All those problems bugged me for a while 
 now so I stared working on that using the bulkpostings API. I would have done 
 that first cut on trunk but TermScorer is working on BlockReader that do not 
 expose positions while the one in this branch does. I started adding a new 
 Positions class which users can pull from a scorer, to prevent unnecessary 
 positions enums I added ScorerContext#needsPositions and eventually 
 Scorere#needsPayloads to create the corresponding enum on demand. Yet, 
 currently only TermQuery / TermScorer implements this API and other simply 
 return null instead. 
 To show that the API really works and our BulkPostings work fine too with 
 positions I cut over TermSpanQuery to use a TermScorer under the hood and 
 nuked TermSpans entirely. A nice sideeffect of this was that the Position 
 BulkReading implementation got some exercise which now :) work all with 
 positions while Payloads for bulkreading are kind of experimental in the 
 patch and those only work with Standard codec. 
 So all spans now work on top of TermScorer ( I truly hate spans since today ) 
 including the ones that need Payloads (StandardCodec ONLY)!!  I didn't bother 
 to implement the other codecs yet since I want to get feedback on the API and 
 on this first cut before I go one with it. I will upload the corresponding 
 patch in a minute. 
 I also had to cut over SpanQuery.getSpans(IR) to 
 SpanQuery.getSpans(AtomicReaderContext) which I should probably do on trunk 
 first but after that pain today I need a break first :).
 The patch passes all core tests 
 (org.apache.lucene.search.highlight.HighlighterTest still fails but I didn't 
 look into the MemoryIndex BulkPostings API yet)

--
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-3485) Make /browse (files and handlers) dependencies self URL-contained


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

Raphaël Droz updated SOLR-3485:
---

Attachment: SOLR-3485-browse-static-files-URL-1.patch

patch affects the example configuration :
* changes the location of expected for jquery.autocomplete.* and main.css
* creates the corresponding /browse/file solr.admin.ShowFileRequestHandler.

It makes use of the patch provided in issue #SOLR-1833 in order to provide 
access to the restricted set of files absolutely needed and explicitly allowed.

 Make /browse (files and handlers) dependencies self URL-contained
 -

 Key: SOLR-3485
 URL: https://issues.apache.org/jira/browse/SOLR-3485
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0
Reporter: Raphaël Droz
Priority: Minor
 Attachments: SOLR-3485-browse-static-files-URL-1.patch


 Assuming that /browse may be, now or later, safe for a public use it would be 
 very useful to make it self-contained in a given URL pattern in order to 
 allow URL-based access restrictions.
 There are 3 issues here :
 * static files (css/js/img)
 * external handlers like /terms, /clustering
 * pattern switch between /browse/* and /collection1/browse/*
 I only try to address the 1st issue, in the comment below.
 If both /terms and /clustering are safe to be public, then issue 2 may be 
 omitted.

--
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-3485) Make /browse (files and handlers) dependencies self URL-contained


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

Raphaël Droz updated SOLR-3485:
---

Comment: was deleted

(was: Not really a blocker but whitelisting allowed files is probably the 
preferred way.)

 Make /browse (files and handlers) dependencies self URL-contained
 -

 Key: SOLR-3485
 URL: https://issues.apache.org/jira/browse/SOLR-3485
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0
Reporter: Raphaël Droz
Priority: Minor
 Attachments: SOLR-3485-browse-static-files-URL-1.patch


 Assuming that /browse may be, now or later, safe for a public use it would be 
 very useful to make it self-contained in a given URL pattern in order to 
 allow URL-based access restrictions.
 There are 3 issues here :
 * static files (css/js/img)
 * external handlers like /terms, /clustering
 * pattern switch between /browse/* and /collection1/browse/*
 I only try to address the 1st issue, in the comment below.
 If both /terms and /clustering are safe to be public, then issue 2 may be 
 omitted.

--
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] [Comment Edited] (SOLR-3485) Make /browse (files and handlers) dependencies self URL-contained


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

Raphaël Droz edited comment on SOLR-3485 at 5/24/12 1:34 PM:
-

patch affects the example configuration :
* changes the location of expected for jquery.autocomplete.* and main.css
* creates the corresponding /browse/file solr.admin.ShowFileRequestHandler.

It makes use of the patch provided in issue SOLR-1833 in order to provide 
access to the restricted set of files absolutely needed and explicitly allowed.

  was (Author: drzraf):
patch affects the example configuration :
* changes the location of expected for jquery.autocomplete.* and main.css
* creates the corresponding /browse/file solr.admin.ShowFileRequestHandler.

It makes use of the patch provided in issue #SOLR-1833 in order to provide 
access to the restricted set of files absolutely needed and explicitly allowed.
  
 Make /browse (files and handlers) dependencies self URL-contained
 -

 Key: SOLR-3485
 URL: https://issues.apache.org/jira/browse/SOLR-3485
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0
Reporter: Raphaël Droz
Priority: Minor
 Attachments: SOLR-3485-browse-static-files-URL-1.patch


 Assuming that /browse may be, now or later, safe for a public use it would be 
 very useful to make it self-contained in a given URL pattern in order to 
 allow URL-based access restrictions.
 There are 3 issues here :
 * static files (css/js/img)
 * external handlers like /terms, /clustering
 * pattern switch between /browse/* and /collection1/browse/*
 I only try to address the 1st issue, in the comment below.
 If both /terms and /clustering are safe to be public, then issue 2 may be 
 omitted.

--
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-2878) Allow Scorer to expose positions and payloads aka. nuke spans

2012-05-24 Thread Simon Willnauer (JIRA)

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

Simon Willnauer commented on LUCENE-2878:
-

Alan this is awesome. I fixed some compile errors in solr and modules land and
test-core passes! I will go ahead and commit this to the branch.
I think next is either fixing all missing queries (PhraseScorer and friends) or
exposing offsets. Feel free to create a subtask for the offsets though. My
first step here would be to put the offsets next to PositionInterval#begin/end
as offsetBegin/End. This is more of a coding task than anything else in the
beginning since this info needs to be transported up the
PositionIntervalIterator tree during execution. on the lowest level
(TermPositions) you can simply assign it via
DocsAndPositionsEnum#start/endOffset() since that returns -1 if offsets are not
indexed.

thanks good job!

Allow Scorer to expose positions and payloads aka. nuke spans
--

Key: LUCENE-2878
URL: https://issues.apache.org/jira/browse/LUCENE-2878
Project: Lucene - Java
Issue Type: Improvement
Components: core/search
Affects Versions: Positions Branch
Reporter: Simon Willnauer
Assignee: Simon Willnauer
Labels: gsoc2011, gsoc2012, lucene-gsoc-11, lucene-gsoc-12,
mentor
Fix For: Positions Branch

Attachments: LUCENE-2878-OR.patch, LUCENE-2878.patch,
LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch,
LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch,
LUCENE-2878_trunk.patch, LUCENE-2878_trunk.patch, PosHighlighter.patch,
PosHighlighter.patch

Currently we have two somewhat separate types of queries, the one which can
make use of positions (mainly spans) and payloads (spans). Yet Span*Query
doesn't really do scoring comparable to what other queries do and at the end
of the day they are duplicating lot of code all over lucene. Span*Queries are
also limited to other Span*Query instances such that you can not use a
TermQuery or a BooleanQuery with SpanNear or anthing like that.
Beside of the Span*Query limitation other queries lacking a quiet interesting
feature since they can not score based on term proximity since scores doesn't
expose any positional information. All those problems bugged me for a while
now so I stared working on that using the bulkpostings API. I would have done
that first cut on trunk but TermScorer is working on BlockReader that do not
expose positions while the one in this branch does. I started adding a new
Positions class which users can pull from a scorer, to prevent unnecessary
positions enums I added ScorerContext#needsPositions and eventually
Scorere#needsPayloads to create the corresponding enum on demand. Yet,
currently only TermQuery / TermScorer implements this API and other simply
return null instead.
To show that the API really works and our BulkPostings work fine too with
positions I cut over TermSpanQuery to use a TermScorer under the hood and
nuked TermSpans entirely. A nice sideeffect of this was that the Position
BulkReading implementation got some exercise which now :) work all with
positions while Payloads for bulkreading are kind of experimental in the
patch and those only work with Standard codec.
So all spans now work on top of TermScorer ( I truly hate spans since today )
including the ones that need Payloads (StandardCodec ONLY)!! I didn't bother
to implement the other codecs yet since I want to get feedback on the API and
on this first cut before I go one with it. I will upload the corresponding
patch in a minute.
I also had to cut over SpanQuery.getSpans(IR) to
SpanQuery.getSpans(AtomicReaderContext) which I should probably do on trunk
first but after that pain today I need a break first :).
The patch passes all core tests
(org.apache.lucene.search.highlight.HighlighterTest still fails but I didn't
look into the MemoryIndex BulkPostings API yet)

--
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-2878) Allow Scorer to expose positions and payloads aka. nuke spans

2012-05-24 Thread Simon Willnauer (JIRA)

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

Simon Willnauer commented on LUCENE-2878:
-

thanks good job!

Allow Scorer to expose positions and payloads aka. nuke spans
--

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

[jira] [Commented] (LUCENE-2878) Allow Scorer to expose positions and payloads aka. nuke spans


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

Alan Woodward commented on LUCENE-2878:
---

I'll start on the offsets - some relatively mindless coding is probably about 
where I'm at today, and the brief look I had at ExactPhraseScorer scared me a 
bit.

 Allow Scorer to expose positions and payloads aka. nuke spans 
 --

 Key: LUCENE-2878
 URL: https://issues.apache.org/jira/browse/LUCENE-2878
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/search
Affects Versions: Positions Branch
Reporter: Simon Willnauer
Assignee: Simon Willnauer
  Labels: gsoc2011, gsoc2012, lucene-gsoc-11, lucene-gsoc-12, 
 mentor
 Fix For: Positions Branch

 Attachments: LUCENE-2878-OR.patch, LUCENE-2878.patch, 
 LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
 LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
 LUCENE-2878_trunk.patch, LUCENE-2878_trunk.patch, PosHighlighter.patch, 
 PosHighlighter.patch


 Currently we have two somewhat separate types of queries, the one which can 
 make use of positions (mainly spans) and payloads (spans). Yet Span*Query 
 doesn't really do scoring comparable to what other queries do and at the end 
 of the day they are duplicating lot of code all over lucene. Span*Queries are 
 also limited to other Span*Query instances such that you can not use a 
 TermQuery or a BooleanQuery with SpanNear or anthing like that. 
 Beside of the Span*Query limitation other queries lacking a quiet interesting 
 feature since they can not score based on term proximity since scores doesn't 
 expose any positional information. All those problems bugged me for a while 
 now so I stared working on that using the bulkpostings API. I would have done 
 that first cut on trunk but TermScorer is working on BlockReader that do not 
 expose positions while the one in this branch does. I started adding a new 
 Positions class which users can pull from a scorer, to prevent unnecessary 
 positions enums I added ScorerContext#needsPositions and eventually 
 Scorere#needsPayloads to create the corresponding enum on demand. Yet, 
 currently only TermQuery / TermScorer implements this API and other simply 
 return null instead. 
 To show that the API really works and our BulkPostings work fine too with 
 positions I cut over TermSpanQuery to use a TermScorer under the hood and 
 nuked TermSpans entirely. A nice sideeffect of this was that the Position 
 BulkReading implementation got some exercise which now :) work all with 
 positions while Payloads for bulkreading are kind of experimental in the 
 patch and those only work with Standard codec. 
 So all spans now work on top of TermScorer ( I truly hate spans since today ) 
 including the ones that need Payloads (StandardCodec ONLY)!!  I didn't bother 
 to implement the other codecs yet since I want to get feedback on the API and 
 on this first cut before I go one with it. I will upload the corresponding 
 patch in a minute. 
 I also had to cut over SpanQuery.getSpans(IR) to 
 SpanQuery.getSpans(AtomicReaderContext) which I should probably do on trunk 
 first but after that pain today I need a break first :).
 The patch passes all core tests 
 (org.apache.lucene.search.highlight.HighlighterTest still fails but I didn't 
 look into the MemoryIndex BulkPostings API yet)

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



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

Re: SOLR-2923

I'll take it if no one beats me.

On May 24, 2012, at 9:15 AM, Adrien Grand wrote:

 Hi,
 
 Could someone review SOLR-2923 [1]? Although the patch is a little
 old, the bug still exists in trunk and the patch applies correctly.
 
 Thank you!
 
 1. https://issues.apache.org/jira/browse/SOLR-2923
 
 -- 
 Adrien
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 

- Mark Miller
lucidimagination.com












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

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

FWIW, I've been looping this test on my Windows 7 VM and I have not seen a 
single failure.

Perhaps we should have some Windows retry logic? Not the first time we have 
needed that I think.


On May 24, 2012, at 2:29 AM, Uwe Schindler wrote:

 No virus scanners active, but Windows Search in this VM.

Are there excludes for the lucene/solr dirs? Been I while since I was weighed 
down with windows, but that always killed my indexing if I didn't exclude my 
checkout directories.

- Mark Miller
lucidimagination.com












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

[jira] [Commented] (LUCENE-2878) Allow Scorer to expose positions and payloads aka. nuke spans

2012-05-24 Thread Robert Muir (JIRA)


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

Robert Muir commented on LUCENE-2878:
-

its fantastic how you guys have brought this back from the dead!

 Allow Scorer to expose positions and payloads aka. nuke spans 
 --

 Key: LUCENE-2878
 URL: https://issues.apache.org/jira/browse/LUCENE-2878
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/search
Affects Versions: Positions Branch
Reporter: Simon Willnauer
Assignee: Simon Willnauer
  Labels: gsoc2011, gsoc2012, lucene-gsoc-11, lucene-gsoc-12, 
 mentor
 Fix For: Positions Branch

 Attachments: LUCENE-2878-OR.patch, LUCENE-2878.patch, 
 LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
 LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
 LUCENE-2878_trunk.patch, LUCENE-2878_trunk.patch, PosHighlighter.patch, 
 PosHighlighter.patch


 Currently we have two somewhat separate types of queries, the one which can 
 make use of positions (mainly spans) and payloads (spans). Yet Span*Query 
 doesn't really do scoring comparable to what other queries do and at the end 
 of the day they are duplicating lot of code all over lucene. Span*Queries are 
 also limited to other Span*Query instances such that you can not use a 
 TermQuery or a BooleanQuery with SpanNear or anthing like that. 
 Beside of the Span*Query limitation other queries lacking a quiet interesting 
 feature since they can not score based on term proximity since scores doesn't 
 expose any positional information. All those problems bugged me for a while 
 now so I stared working on that using the bulkpostings API. I would have done 
 that first cut on trunk but TermScorer is working on BlockReader that do not 
 expose positions while the one in this branch does. I started adding a new 
 Positions class which users can pull from a scorer, to prevent unnecessary 
 positions enums I added ScorerContext#needsPositions and eventually 
 Scorere#needsPayloads to create the corresponding enum on demand. Yet, 
 currently only TermQuery / TermScorer implements this API and other simply 
 return null instead. 
 To show that the API really works and our BulkPostings work fine too with 
 positions I cut over TermSpanQuery to use a TermScorer under the hood and 
 nuked TermSpans entirely. A nice sideeffect of this was that the Position 
 BulkReading implementation got some exercise which now :) work all with 
 positions while Payloads for bulkreading are kind of experimental in the 
 patch and those only work with Standard codec. 
 So all spans now work on top of TermScorer ( I truly hate spans since today ) 
 including the ones that need Payloads (StandardCodec ONLY)!!  I didn't bother 
 to implement the other codecs yet since I want to get feedback on the API and 
 on this first cut before I go one with it. I will upload the corresponding 
 patch in a minute. 
 I also had to cut over SpanQuery.getSpans(IR) to 
 SpanQuery.getSpans(AtomicReaderContext) which I should probably do on trunk 
 first but after that pain today I need a break first :).
 The patch passes all core tests 
 (org.apache.lucene.search.highlight.HighlighterTest still fails but I didn't 
 look into the MemoryIndex BulkPostings API yet)

--
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-139) Support updateable/modifiable documents

2012-05-24 Thread Yonik Seeley (JIRA)


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

Yonik Seeley commented on SOLR-139:
---

bq. The schema has price and price_c (copy field from price)

For this feature to work correctly, source fields (the ones you normally send 
in) should be stored, and copyField targets (like price_c) should be un-stored.

 Support updateable/modifiable documents
 ---

 Key: SOLR-139
 URL: https://issues.apache.org/jira/browse/SOLR-139
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Ryan McKinley
 Attachments: Eriks-ModifiableDocument.patch, 
 Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, 
 Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, 
 Eriks-ModifiableDocument.patch, SOLR-139-IndexDocumentCommand.patch, 
 SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, 
 SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, 
 SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, 
 SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, 
 SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, 
 SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, 
 SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, 
 SOLR-139-XmlUpdater.patch, SOLR-139.patch, SOLR-139.patch, 
 SOLR-269+139-ModifiableDocumentUpdateProcessor.patch, getStoredFields.patch, 
 getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, 
 getStoredFields
 .patch


 It would be nice to be able to update some fields on a document without 
 having to insert the entire document.
 Given the way lucene is structured, (for now) one can only modify stored 
 fields.
 While we are at it, we can support incrementing an existing value - I think 
 this only makes sense for numbers.
 for background, see:
 http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293

--
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-4006) system requirements is duplicated across versioned/unversioned

2012-05-24 Thread Uwe Schindler (JIRA)


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

Uwe Schindler commented on LUCENE-4006:
---

LUCENE-1154 is the reason for the duplication:
- We had at that time no per-release docs with sysreqs. So at the time of 3.0, 
we had to support previous Lucene versions, too (which had no sysreq docs). So 
the general info is on the web page.

As we already removed the 2.x releases from the website, we no longer need the 
sysreqs global page and just refer to the per-version docs.

For Lucene 4.0 ewe have to add a markdown version to the release bundle.

 system requirements is duplicated across versioned/unversioned
 --

 Key: LUCENE-4006
 URL: https://issues.apache.org/jira/browse/LUCENE-4006
 Project: Lucene - Java
  Issue Type: Task
  Components: general/javadocs
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 4.0


 Our System requirements page is located here on the unversioned site: 
 http://lucene.apache.org/core/systemreqs.html
 But its also in forrest under each release. Can we just nuke the forrested 
 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] [Comment Edited] (LUCENE-4006) system requirements is duplicated across versioned/unversioned

2012-05-24 Thread Uwe Schindler (JIRA)

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

Uwe Schindler edited comment on LUCENE-4006 at 5/24/12 2:48 PM:

LUCENE-1154 is the reason for the duplication: We had at that time no
per-release docs with sysreqs. So at the time of 3.0, we had to support
previous Lucene versions, too (which had no sysreq docs). So the general info
is on the web page.

As we already removed the 2.x releases from the website, we no longer need the
sysreqs global page and just refer to the per-version docs.

For Lucene 4.0 ewe have to add a markdown version to the release bundle.

was (Author: thetaphi):
LUCENE-1154 is the reason for the duplication:
- We had at that time no per-release docs with sysreqs. So at the time of 3.0,
we had to support previous Lucene versions, too (which had no sysreq docs). So
the general info is on the web page.

As we already removed the 2.x releases from the website, we no longer need the
sysreqs global page and just refer to the per-version docs.

For Lucene 4.0 ewe have to add a markdown version to the release bundle.

system requirements is duplicated across versioned/unversioned
--

Key: LUCENE-4006
URL: https://issues.apache.org/jira/browse/LUCENE-4006
Project: Lucene - Java
Issue Type: Task
Components: general/javadocs
Reporter: Robert Muir
Assignee: Uwe Schindler
Fix For: 4.0

Our System requirements page is located here on the unversioned site:
http://lucene.apache.org/core/systemreqs.html
But its also in forrest under each release. Can we just nuke the forrested
one?

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

[jira] [Comment Edited] (LUCENE-4006) system requirements is duplicated across versioned/unversioned

2012-05-24 Thread Uwe Schindler (JIRA)


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

Uwe Schindler edited comment on LUCENE-4006 at 5/24/12 2:49 PM:


-Robert: The forrested one is now gone as we used a chainsaw, right? So I think 
we can close this issue :-)-

  was (Author: thetaphi):
Robert: The forrested one is now gone as we used a chainsaw, right? So I 
think we can close this issue :-)
  
 system requirements is duplicated across versioned/unversioned
 --

 Key: LUCENE-4006
 URL: https://issues.apache.org/jira/browse/LUCENE-4006
 Project: Lucene - Java
  Issue Type: Task
  Components: general/javadocs
Reporter: Robert Muir
Assignee: Uwe Schindler
 Fix For: 4.0


 Our System requirements page is located here on the unversioned site: 
 http://lucene.apache.org/core/systemreqs.html
 But its also in forrest under each release. Can we just nuke the forrested 
 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

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

2012-05-24 Thread Uwe Schindler

Hi,

The Jenkins Workspace is installed c:\Jenkins, so outside home dir. In that
case it should not be affected by Indexing. I can check this later.

 FWIW, I've been looping this test on my Windows 7 VM and I have not seen a
 single failure.

It happens not all the time. Just as reminder: This VM has 2 virtual
CPUs/cores!

 Perhaps we should have some Windows retry logic? Not the first time we
have
 needed that I think.

Lucene itsself has it.

 
 On May 24, 2012, at 2:29 AM, Uwe Schindler wrote:
 
  No virus scanners active, but Windows Search in this VM.
 
 Are there excludes for the lucene/solr dirs? Been I while since I was
weighed
 down with windows, but that always killed my indexing if I didn't exclude
my
 checkout directories.
 
 - Mark Miller
 lucidimagination.com
 
 
 
 
 
 
 
 
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
 commands, e-mail: dev-h...@lucene.apache.org


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

[jira] [Commented] (LUCENE-3523) WordBreakSpellChecker

2012-05-24 Thread James Dyer (JIRA)


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

James Dyer commented on LUCENE-3523:


This patch contains a standalone feature and doesn't affect anything else.  I 
would like to commit this sometime soon (and SOLR-2993 to integrate word-break 
spelling corrections in Solr).  This is a feature our previous search engine 
has that Lucene/Solr so far do not have.

 WordBreakSpellChecker
 -

 Key: LUCENE-3523
 URL: https://issues.apache.org/jira/browse/LUCENE-3523
 Project: Lucene - Java
  Issue Type: Improvement
  Components: modules/spellchecker
Affects Versions: 3.5, 4.0
Reporter: James Dyer
Priority: Minor
 Fix For: 4.1

 Attachments: LUCENE-3523.patch, LUCENE-3523.patch, LUCENE-3523.patch, 
 LUCENE-3523.patch


 A spellchecker that generates suggestions by combining two or more terms 
 and/or breaking terms into multiple words. This would typically be used in 
 addition to one of the existing spell checkers to get both traditional and 
 word-break suggestions for the end user.

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



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

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

Finally got the same fail on my Windows virt machine - seems harder for me to 
see, but at least a confirmation.

- Mark Miller
lucidimagination.com












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

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


On May 24, 2012, at 10:55 AM, Uwe Schindler wrote:

 Hi,
 
 The Jenkins Workspace is installed c:\Jenkins, so outside home dir. In that
 case it should not be affected by Indexing. I can check this later.

makes sense - my workspace was in mydocs half the time, or my user dir.

 
 FWIW, I've been looping this test on my Windows 7 VM and I have not seen a
 single failure.
 
 It happens not all the time. Just as reminder: This VM has 2 virtual
 CPUs/cores!

My virt machine also has 2 virtual cores. I ran the test over 100 times before 
I got a failure - so it won't be easy for me to test any fix attempts - we will 
probably have to just commit something and wait and see what happens on your 
jenkins runs.

 
 Perhaps we should have some Windows retry logic? Not the first time we
 have
 needed that I think.
 
 Lucene itsself has it.

I'm not sure this is the issue yet, but it might be worth a try.

 
 
 On May 24, 2012, at 2:29 AM, Uwe Schindler wrote:
 
 No virus scanners active, but Windows Search in this VM.
 
 Are there excludes for the lucene/solr dirs? Been I while since I was
 weighed
 down with windows, but that always killed my indexing if I didn't exclude
 my
 checkout directories.
 
 - Mark Miller
 lucidimagination.com
 
 
 
 
 
 
 
 
 
 
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional
 commands, e-mail: dev-h...@lucene.apache.org
 
 
 -
 To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
 For additional commands, e-mail: dev-h...@lucene.apache.org
 

- Mark Miller
lucidimagination.com












-
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 #111

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

--
[...truncated 14543 lines...]
   [junit4]   2 74303 T2922 oasc.RequestHandlers.initHandlersFromConfig 
created spellCheckCompRH1: org.apache.solr.handler.component.SearchHandler
   [junit4]   2 74304 T2922 oasc.RequestHandlers.initHandlersFromConfig 
created tvrh: org.apache.solr.handler.component.SearchHandler
   [junit4]   2 74304 T2922 oasc.RequestHandlers.initHandlersFromConfig 
created /mlt: solr.MoreLikeThisHandler
   [junit4]   2 74304 T2922 oasc.RequestHandlers.initHandlersFromConfig 
created /debug/dump: solr.DumpRequestHandler
   [junit4]   2 74305 T2922 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
   [junit4]   2 74308 T2922 oasc.SolrCore.initDeprecatedSupport WARNING 
solrconfig.xml uses deprecated admin/gettableFiles, Please update your config 
to use the ShowFileRequestHandler.
   [junit4]   2 74311 T2922 oasc.SolrCore.initDeprecatedSupport WARNING adding 
ShowFileRequestHandler with hidden files: [SOLRCONFIG-HIGHLIGHT.XML, 
SCHEMA-REQUIRED-FIELDS.XML, SCHEMA-REPLICATION2.XML, SCHEMA-MINIMAL.XML, 
BAD-SCHEMA-DUP-DYNAMICFIELD.XML, SOLRCONFIG-CACHING.XML, 
SOLRCONFIG-REPEATER.XML, CURRENCY.XML, BAD-SCHEMA-NONTEXT-ANALYZER.XML, 
SOLRCONFIG-MERGEPOLICY.XML, SOLRCONFIG-TLOG.XML, SOLRCONFIG-MASTER.XML, 
SCHEMA11.XML, SOLRCONFIG-BASIC.XML, DA_COMPOUNDDICTIONARY.TXT, 
SCHEMA-COPYFIELD-TEST.XML, SOLRCONFIG-SLAVE.XML, ELEVATE.XML, 
SOLRCONFIG-PROPINJECT-INDEXDEFAULT.XML, SCHEMA-IB.XML, 
SOLRCONFIG-QUERYSENDER.XML, SCHEMA-REPLICATION1.XML, DA_UTF8.XML, 
HYPHENATION.DTD, SOLRCONFIG-ENABLEPLUGIN.XML, STEMDICT.TXT, 
SCHEMA-PHRASESUGGEST.XML, HUNSPELL-TEST.AFF, STOPTYPES-1.TXT, 
STOPWORDSWRONGENCODING.TXT, SCHEMA-NUMERIC.XML, SOLRCONFIG-TRANSFORMERS.XML, 
SOLRCONFIG-PROPINJECT.XML, BAD-SCHEMA-NOT-INDEXED-BUT-TF.XML, 
SOLRCONFIG-SIMPLELOCK.XML, WDFTYPES.TXT, STOPTYPES-2.TXT, SCHEMA-REVERSED.XML, 
SOLRCONFIG-SPELLCHECKCOMPONENT.XML, SCHEMA-DFR.XML, 
SOLRCONFIG-PHRASESUGGEST.XML, BAD-SCHEMA-NOT-INDEXED-BUT-POS.XML, KEEP-1.TXT, 
OPEN-EXCHANGE-RATES.JSON, STOPWITHBOM.TXT, SCHEMA-BINARYFIELD.XML, 
SOLRCONFIG-SPELLCHECKER.XML, SOLRCONFIG-UPDATE-PROCESSOR-CHAINS.XML, 
BAD-SCHEMA-OMIT-TF-BUT-NOT-POS.XML, BAD-SCHEMA-DUP-FIELDTYPE.XML, 
SOLRCONFIG-MASTER1.XML, SYNONYMS.TXT, SCHEMA.XML, SCHEMA_CODEC.XML, 
SOLRCONFIG-SOLR-749.XML, SOLRCONFIG-MASTER1-KEEPONEBACKUP.XML, STOP-2.TXT, 
SOLRCONFIG-FUNCTIONQUERY.XML, SCHEMA-LMDIRICHLET.XML, SOLRCONFIG-TERMINDEX.XML, 
SOLRCONFIG-ELEVATE.XML, STOPWORDS.TXT, SCHEMA-FOLDING.XML, 
SCHEMA-STOP-KEEP.XML, BAD-SCHEMA-NOT-INDEXED-BUT-NORMS.XML, 
SOLRCONFIG-SOLCOREPROPERTIES.XML, STOP-1.TXT, SOLRCONFIG-MASTER2.XML, 
SCHEMA-SPELLCHECKER.XML, SOLRCONFIG-LAZYWRITER.XML, 
SCHEMA-LUCENEMATCHVERSION.XML, BAD-MP-SOLRCONFIG.XML, FRENCHARTICLES.TXT, 
SCHEMA15.XML, SOLRCONFIG-REQHANDLER.INCL, SCHEMASURROUND.XML, 
SCHEMA-COLLATEFILTER.XML, SOLRCONFIG-MASTER3.XML, HUNSPELL-TEST.DIC, 
SOLRCONFIG-XINCLUDE.XML, SOLRCONFIG-DELPOLICY1.XML, SOLRCONFIG-SLAVE1.XML, 
SCHEMA-SIM.XML, SCHEMA-COLLATE.XML, STOP-SNOWBALL.TXT, PROTWORDS.TXT, 
SCHEMA-TRIE.XML, SOLRCONFIG_CODEC.XML, SCHEMA-TFIDF.XML, 
SCHEMA-LMJELINEKMERCER.XML, PHRASESUGGEST.TXT, 
SOLRCONFIG-BASIC-LUCENEVERSION31.XML, OLD_SYNONYMS.TXT, 
SOLRCONFIG-DELPOLICY2.XML, XSLT, SOLRCONFIG-NATIVELOCK.XML, 
BAD-SCHEMA-DUP-FIELD.XML, SOLRCONFIG-NOCACHE.XML, SCHEMA-BM25.XML, 
SOLRCONFIG-ALTDIRECTORY.XML, SOLRCONFIG-QUERYSENDER-NOQUERY.XML, 
COMPOUNDDICTIONARY.TXT, SOLRCONFIG_PERF.XML, 
SCHEMA-NOT-REQUIRED-UNIQUE-KEY.XML, KEEP-2.TXT, SCHEMA12.XML, 
MAPPING-ISOLATIN1ACCENT.TXT, BAD_SOLRCONFIG.XML, 
BAD-SCHEMA-EXTERNAL-FILEFIELD.XML]
   [junit4]   2 74315 T2922 oass.SolrIndexSearcher.init Opening 
Searcher@43531425 main
   [junit4]   2 74316 T2922 oass.SolrIndexSearcher.init WARNING WARNING: 
Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
   [junit4]   2 74316 T2922 oasu.CommitTracker.init Hard AutoCommit: disabled
   [junit4]   2 74316 T2922 oasu.CommitTracker.init Soft AutoCommit: disabled
   [junit4]   2 74317 T2922 oashc.SpellCheckComponent.inform Initializing 
spell checkers
   [junit4]   2 74322 T2922 oass.DirectSolrSpellChecker.init init: 
{name=direct,classname=DirectSolrSpellChecker,field=lowerfilt,minQueryLength=3}
   [junit4]   2 74368 T2922 oashc.HttpShardHandlerFactory.getParameter Setting 
socketTimeout to: 0
   [junit4]   2 74369 T2922 oashc.HttpShardHandlerFactory.getParameter Setting 
urlScheme to: http://
   [junit4]   2 74369 T2922 oashc.HttpShardHandlerFactory.getParameter Setting 
connTimeout to: 0
   [junit4]   2 74369 T2922 oashc.HttpShardHandlerFactory.getParameter Setting 
maxConnectionsPerHost to: 20
   [junit4]   2 74369 T2922 oashc.HttpShardHandlerFactory.getParameter Setting 
corePoolSize to: 0
   [junit4]   2 74369 T2922 oashc.HttpShardHandlerFactory.getParameter Setting 
maximumPoolSize to: 2147483647
   [junit4]   2 74369 T2922

[jira] [Created] (SOLR-3486) The memory size of Solr caches should be configurable

2012-05-24 Thread Adrien Grand (JIRA)

Adrien Grand created SOLR-3486:
--

 Summary: The memory size of Solr caches should be configurable
 Key: SOLR-3486
 URL: https://issues.apache.org/jira/browse/SOLR-3486
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Adrien Grand
Priority: Minor


It is currently possible to configure the sizes of Solr caches based on the 
number of entries of the cache. The problem is that the memory size of cached 
values may vary a lot over time (depending on IndexReader.maxDoc and the 
queries that are run) although the JVM heap size does not.

Having a configurable max size in bytes would also help optimize cache 
utilization, making it possible to store more values provided that they have a 
small memory footprint.

--
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-3319) Cut over remaining queries to provide PositionIterators

2012-05-24 Thread John Berryman (JIRA)


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

John Berryman commented on LUCENE-3319:
---

I'm interested in helping out. Digging now...

 Cut over remaining queries to provide PositionIterators
 ---

 Key: LUCENE-3319
 URL: https://issues.apache.org/jira/browse/LUCENE-3319
 Project: Lucene - Java
  Issue Type: Sub-task
  Components: core/search
Affects Versions: Positions Branch
Reporter: Simon Willnauer
Assignee: Simon Willnauer
 Fix For: Positions Branch


 most queries already providing positions but some are still missing. This 
 issue / subtask will track progress along those lines.

--
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-3486) The memory size of Solr caches should be configurable

2012-05-24 Thread Adrien Grand (JIRA)


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

Adrien Grand updated SOLR-3486:
---

Attachment: SOLR-3486.patch

This patch makes the maximum memory size of LRUCache configurable. It would be 
nice to add the same feature to the concurrent caches although I expect it to 
be a little more tricky.

 The memory size of Solr caches should be configurable
 -

 Key: SOLR-3486
 URL: https://issues.apache.org/jira/browse/SOLR-3486
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Adrien Grand
Priority: Minor
 Attachments: SOLR-3486.patch


 It is currently possible to configure the sizes of Solr caches based on the 
 number of entries of the cache. The problem is that the memory size of cached 
 values may vary a lot over time (depending on IndexReader.maxDoc and the 
 queries that are run) although the JVM heap size does not.
 Having a configurable max size in bytes would also help optimize cache 
 utilization, making it possible to store more values provided that they have 
 a small memory footprint.

--
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 #112

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


-
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 # 14312 - Failure

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

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

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

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=80 closes=79
at __randomizedtesting.SeedInfo.seed([E714556D7A9EDDF5]: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.GeneratedMethodAccessor14.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 10334 lines...]



-
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 #114

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

--
[...truncated 14622 lines...]
   [junit4] Suite: org.apache.solr.update.DirectUpdateHandlerOptimizeTest
   [junit4] Completed in 1.62s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.analysis.TestStopFilterFactory
   [junit4] Completed in 0.02s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestQuerySenderNoQuery
   [junit4] Completed in 1.39s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.BadComponentTest
   [junit4] Completed in 1.38s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.TestCSVLoader
   [junit4] Completed in 2.43s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestRealTimeGet
   [junit4] IGNOR/A 0.02s | TestRealTimeGet.testStressRecovery
   [junit4] Assumption #1: FIXME: This test is horribly slow sometimes on 
Windows!
   [junit4]   2 25041 T2817 oas.SolrTestCaseJ4.setUp ###Starting 
testStressRecovery
   [junit4]   2 25041 T2817 oas.SolrTestCaseJ4.tearDown ###Ending 
testStressRecovery
   [junit4]   2
   [junit4] Completed in 35.77s, 8 tests, 1 skipped
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestRecovery
   [junit4] Completed in 13.73s, 9 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.BasicZkTest
   [junit4] Completed in 9.81s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.cloud.TestHashPartitioner
   [junit4] Completed in 9.93s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.SpellCheckComponentTest
   [junit4] Completed in 6.71s, 9 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.request.SimpleFacetsTest
   [junit4] Completed in 8.65s, 29 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.handler.component.DistributedQueryElevationComponentTest
   [junit4] Completed in 6.18s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.MoreLikeThisHandlerTest
   [junit4] Completed in 1.48s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.SolrCoreTest
   [junit4] Completed in 8.72s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.servlet.SolrRequestParserTest
   [junit4] Completed in 2.31s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.spelling.suggest.SuggesterTest
   [junit4] Completed in 2.04s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestCoreContainer
   [junit4] Completed in 4.19s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestSolrDeletionPolicy2
   [junit4] Completed in 1.17s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.TermsComponentTest
   [junit4] Completed in 1.52s, 13 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.function.SortByFunctionTest
   [junit4] Completed in 3.01s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.DocumentBuilderTest
   [junit4] Completed in 1.26s, 11 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.function.distance.DistanceFunctionTest
   [junit4] Completed in 1.37s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.request.TestBinaryResponseWriter
   [junit4] Completed in 2.04s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.servlet.NoCacheHeaderTest
   [junit4] Completed in 1.21s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.CopyFieldTest
   [junit4] Completed in 1.27s, 6 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.highlight.FastVectorHighlighterTest
   [junit4] Completed in 1.19s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.update.SolrIndexConfigTest
   [junit4] Completed in 2.02s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.component.DebugComponentTest
   [junit4] Completed in 1.50s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestQueryUtils
   [junit4] Completed in 1.59s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.DisMaxRequestHandlerTest
   [junit4] Completed in 1.41s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.IndexReaderFactoryTest
   [junit4] Completed in 1.15s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestExtendedDismaxParser
   [junit4] Completed in 9.19s, 8 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.core.TestArbitraryIndexDir
   [junit4] Completed in 0.98s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.FieldAnalysisRequestHandlerTest
   [junit4] Completed in 0.93s, 4 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.search.TestSolrQueryParser
   [junit4] Completed in 0.91s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.schema.IndexSchemaRuntimeFieldTest
   [junit4] Completed in 1.04s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.handler.admin.MBeansHandlerTest
   [junit4] Completed in 1.21s, 1 test
   [junit4]  
   [junit4] Suite:

[jira] [Updated] (LUCENE-2878) Allow Scorer to expose positions and payloads aka. nuke spans


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

Alan Woodward updated LUCENE-2878:
--

Attachment: LUCENE-2878.patch

Patch against the branch head, adding offsets to PositionInterval.  Includes a 
couple of test cases showing that it works for basic TermQueries.


 Allow Scorer to expose positions and payloads aka. nuke spans 
 --

 Key: LUCENE-2878
 URL: https://issues.apache.org/jira/browse/LUCENE-2878
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/search
Affects Versions: Positions Branch
Reporter: Simon Willnauer
Assignee: Simon Willnauer
  Labels: gsoc2011, gsoc2012, lucene-gsoc-11, lucene-gsoc-12, 
 mentor
 Fix For: Positions Branch

 Attachments: LUCENE-2878-OR.patch, LUCENE-2878.patch, 
 LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
 LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
 LUCENE-2878.patch, LUCENE-2878_trunk.patch, LUCENE-2878_trunk.patch, 
 PosHighlighter.patch, PosHighlighter.patch


 Currently we have two somewhat separate types of queries, the one which can 
 make use of positions (mainly spans) and payloads (spans). Yet Span*Query 
 doesn't really do scoring comparable to what other queries do and at the end 
 of the day they are duplicating lot of code all over lucene. Span*Queries are 
 also limited to other Span*Query instances such that you can not use a 
 TermQuery or a BooleanQuery with SpanNear or anthing like that. 
 Beside of the Span*Query limitation other queries lacking a quiet interesting 
 feature since they can not score based on term proximity since scores doesn't 
 expose any positional information. All those problems bugged me for a while 
 now so I stared working on that using the bulkpostings API. I would have done 
 that first cut on trunk but TermScorer is working on BlockReader that do not 
 expose positions while the one in this branch does. I started adding a new 
 Positions class which users can pull from a scorer, to prevent unnecessary 
 positions enums I added ScorerContext#needsPositions and eventually 
 Scorere#needsPayloads to create the corresponding enum on demand. Yet, 
 currently only TermQuery / TermScorer implements this API and other simply 
 return null instead. 
 To show that the API really works and our BulkPostings work fine too with 
 positions I cut over TermSpanQuery to use a TermScorer under the hood and 
 nuked TermSpans entirely. A nice sideeffect of this was that the Position 
 BulkReading implementation got some exercise which now :) work all with 
 positions while Payloads for bulkreading are kind of experimental in the 
 patch and those only work with Standard codec. 
 So all spans now work on top of TermScorer ( I truly hate spans since today ) 
 including the ones that need Payloads (StandardCodec ONLY)!!  I didn't bother 
 to implement the other codecs yet since I want to get feedback on the API and 
 on this first cut before I go one with it. I will upload the corresponding 
 patch in a minute. 
 I also had to cut over SpanQuery.getSpans(IR) to 
 SpanQuery.getSpans(AtomicReaderContext) which I should probably do on trunk 
 first but after that pain today I need a break first :).
 The patch passes all core tests 
 (org.apache.lucene.search.highlight.HighlighterTest still fails but I didn't 
 look into the MemoryIndex BulkPostings API yet)

--
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-2878) Allow Scorer to expose positions and payloads aka. nuke spans


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

Alan Woodward commented on LUCENE-2878:
---

The patch also includes an @Ignored test case for BooleanQueries, as this 
didn't behave in the way I expected it to.  At the moment, 
ConjunctionPositionIterator returns PositionIntervals that span all the parent 
query's subclauses.  So searching for 'porridge' and 'nine' returns an Interval 
that starts at 'porridge' and ends at 'nine'.  I would have expected this 
instead to return two separate intervals - if we want phrase-type intervals, 
then we can combine the individual intervals with a Filter of some kind.  But I 
may just be misunderstanding how this is supposed to work.

 Allow Scorer to expose positions and payloads aka. nuke spans 
 --

 Key: LUCENE-2878
 URL: https://issues.apache.org/jira/browse/LUCENE-2878
 Project: Lucene - Java
  Issue Type: Improvement
  Components: core/search
Affects Versions: Positions Branch
Reporter: Simon Willnauer
Assignee: Simon Willnauer
  Labels: gsoc2011, gsoc2012, lucene-gsoc-11, lucene-gsoc-12, 
 mentor
 Fix For: Positions Branch

 Attachments: LUCENE-2878-OR.patch, LUCENE-2878.patch, 
 LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
 LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, LUCENE-2878.patch, 
 LUCENE-2878.patch, LUCENE-2878_trunk.patch, LUCENE-2878_trunk.patch, 
 PosHighlighter.patch, PosHighlighter.patch


 Currently we have two somewhat separate types of queries, the one which can 
 make use of positions (mainly spans) and payloads (spans). Yet Span*Query 
 doesn't really do scoring comparable to what other queries do and at the end 
 of the day they are duplicating lot of code all over lucene. Span*Queries are 
 also limited to other Span*Query instances such that you can not use a 
 TermQuery or a BooleanQuery with SpanNear or anthing like that. 
 Beside of the Span*Query limitation other queries lacking a quiet interesting 
 feature since they can not score based on term proximity since scores doesn't 
 expose any positional information. All those problems bugged me for a while 
 now so I stared working on that using the bulkpostings API. I would have done 
 that first cut on trunk but TermScorer is working on BlockReader that do not 
 expose positions while the one in this branch does. I started adding a new 
 Positions class which users can pull from a scorer, to prevent unnecessary 
 positions enums I added ScorerContext#needsPositions and eventually 
 Scorere#needsPayloads to create the corresponding enum on demand. Yet, 
 currently only TermQuery / TermScorer implements this API and other simply 
 return null instead. 
 To show that the API really works and our BulkPostings work fine too with 
 positions I cut over TermSpanQuery to use a TermScorer under the hood and 
 nuked TermSpans entirely. A nice sideeffect of this was that the Position 
 BulkReading implementation got some exercise which now :) work all with 
 positions while Payloads for bulkreading are kind of experimental in the 
 patch and those only work with Standard codec. 
 So all spans now work on top of TermScorer ( I truly hate spans since today ) 
 including the ones that need Payloads (StandardCodec ONLY)!!  I didn't bother 
 to implement the other codecs yet since I want to get feedback on the API and 
 on this first cut before I go one with it. I will upload the corresponding 
 patch in a minute. 
 I also had to cut over SpanQuery.getSpans(IR) to 
 SpanQuery.getSpans(AtomicReaderContext) which I should probably do on trunk 
 first but after that pain today I need a break first :).
 The patch passes all core tests 
 (org.apache.lucene.search.highlight.HighlighterTest still fails but I didn't 
 look into the MemoryIndex BulkPostings API yet)

--
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 #539

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

--
[...truncated 13932 lines...]
   [junit4]at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   [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$7.evaluate(RandomizedRunner.java:873)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:889)
   [junit4]at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
   [junit4]at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
   [junit4]at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
   [junit4]at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
   [junit4]at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
   [junit4]at 
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
   [junit4]at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
   [junit4]at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:821)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:669)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:695)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:734)
   [junit4]at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:745)
   [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] Caused by: org.apache.lucene.store.AlreadyClosedException: 
this IndexWriter is closed
   [junit4]at 
org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:552)
   [junit4]at 
org.apache.lucene.index.IndexWriter.ensureOpen(IndexWriter.java:557)
   [junit4]at 
org.apache.lucene.index.IndexWriter.deleteAll(IndexWriter.java:1833)
   [junit4]at 
org.apache.solr.update.DirectUpdateHandler2.deleteAll(DirectUpdateHandler2.java:140)
   [junit4]at 
org.apache.solr.update.DirectUpdateHandler2.deleteByQuery(DirectUpdateHandler2.java:292)

[jira] [Resolved] (SOLR-3484) LogUpdateProcessor throws ConcurrentModificationException under multi-threading calls

2012-05-24 Thread Hoss Man (JIRA)


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

Hoss Man resolved SOLR-3484.


Resolution: Not A Problem

See comments in SOLR-2694, particularly Mikhail Khludnev added a comment - 
24/May/12 07:15 (the author of hte patch in question) in direct response to 
comment from creator of this issue.

All of the UpdateProcessor Factories are thread safe -- but *NONE* of the 
UpdateRequestProcessor classes returned by those factories are thread safe.  
UpdateRequestProcessors are designed to be used in the context of a single Solr 
request (hence the reason you need a SolrQueryRequest/SolrQueryResponse to get 
an instance).  If code interacting with an UpdateRequestProcessor is 
multi-threaded, then _that_ client code needs to synchronize it's use of the 
UpdateRequestProcessor.

(This was the fundamental problem in SOLR-2804: multi-threaded DIH code was not 
using the UpdateRequestProcessor in a thread-safe manner).

Adding a ConcurrentLogUpdateRequestProcessor will not magically make it safe 
for multi-threaded code to call methods on an UpdateRequestProcessor chain -- 
because any of the other UpdateRequestProcessors in that chain are also likley 
to break from concurrent usage by multiple threads.

If you have custom code that uses UpdateRequestProcessors in a way that you 
believe is valid, and you still see a bug, then you need to provide a test case 
demonstrating your usage and the bug it produces -- based on comments posted 
here and in SOLR-2694 it seems like the usage being described is not valid, 
because it assumes any and all UpdateRequestProcessors are stateless and 
multi-thread-safe, which is not true.  trivial example: 
RunUpdateProcessorFactory maintains un-synchronized state about uncommited 
changes for dealing with the transaction log.

 LogUpdateProcessor throws ConcurrentModificationException under 
 multi-threading calls 
 --

 Key: SOLR-3484
 URL: https://issues.apache.org/jira/browse/SOLR-3484
 Project: Solr
  Issue Type: Bug
  Components: update
Affects Versions: 4.0
 Environment: linux
Reporter: Ethan Tao

 Using the LogUpdateProcessor in a singleton chain for concurrent processing 
 throws exception. The issue has been reported in SOLR-2694 (closed), and an 
 unoffical patch can be found in related bug-id SOLR-2804 patch dated 1/1/12.
 If the patch won't become official for LogUpdateProcessor, suggested to have 
 new class ConcurrentLogUpdateProcessorFactory to address the thread safe 
 issue.

--
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-4055) Refactor SegmentInfo / FieldInfo to make them extensible

2012-05-24 Thread Robert Muir (JIRA)


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

Robert Muir updated LUCENE-4055:


Attachment: LUCENE-4055.patch

The last nocommits are cleared up: I think the branch is ready to be merged.

Attached is a patch showing the differences between trunk and branch.

 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

 Attachments: LUCENE-4055.patch


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

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



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

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

Just noticed this seems to happen fairly frequently in the java 7 windows 
build, but I don't seem to see it in the java 6 windows build.

I'll try and use Java 7 on my win machine when I get chance - should make it 
easier to experiment with fixes if I can get the same results locally.
-
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 #540

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


-
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 #115

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


-
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 # 14316 - Failure

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

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([8C16FAE4D8C1D524]: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 10472 lines...]



-
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 #544

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

--
[...truncated 10600 lines...]
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-Java6-64/checkout/solr/build/solr-solrj/classes/test
[javac] Compiling 47 source files to 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/solr/build/solr-solrj/classes/test
[javac] Note: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-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.

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-Java6-64/checkout/lucene/ivy-settings.xml

resolve:

init:

compile-core:

validate:

common.test:
[mkdir] Created dir: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux-Java6-64/checkout/solr/build/solr-solrj/test
   [junit4] JUnit4 says hello! Master seed: 7E719B57C96F185D
   [junit4] Executing 40 suites with 2 JVMs.
   [junit4] Suite: org.apache.solr.common.params.SolrParamTest
   [junit4] Completed on J1 in 0.28s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.common.util.TestFastInputStream
   [junit4] Completed on J0 in 0.23s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.SolrQueryTest
   [junit4] Completed on J1 in 0.08s, 9 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.response.TestSpellCheckResponse
   [junit4] Completed on J0 in 3.00s, 3 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.util.ClientUtilsTest
   [junit4] Completed on J0 in 0.01s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.common.SolrDocumentTest
   [junit4] Completed on J0 in 0.06s, 5 tests
   [junit4]  
   [junit4] Suite: 
org.apache.solr.client.solrj.embedded.LargeVolumeBinaryJettyTest
   [junit4] Completed on J1 in 3.60s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.embedded.TestEmbeddedSolrServer
   [junit4] Completed on J1 in 0.95s, 2 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.common.params.ModifiableSolrParamsTest
   [junit4] Completed on J1 in 0.04s, 5 tests
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.embedded.LargeVolumeJettyTest
   [junit4] Completed on J1 in 1.15s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.client.solrj.response.TermsResponseTest
   [junit4] Completed on J0 in 1.07s, 1 test
   [junit4]  
   [junit4] Suite: org.apache.solr.common.util.ContentStreamTest
   [junit4] ERROR   2.63s J0 | ContentStreamTest.testURLStream
   [junit4] Throwable #1: java.net.SocketTimeoutException: Read timed out
   [junit4]at 
__randomizedtesting.SeedInfo.seed([7E719B57C96F185D:4EF58C7E3DDBCED9]:0)
   [junit4]at 
sun.reflect.NativeConstructorAccessorImpl.newInstance0(Native Method)
   [junit4]at 
sun.reflect.NativeConstructorAccessorImpl.newInstance(NativeConstructorAccessorImpl.java:39)
   [junit4]at 
sun.reflect.DelegatingConstructorAccessorImpl.newInstance(DelegatingConstructorAccessorImpl.java:27)
   [junit4]at 
java.lang.reflect.Constructor.newInstance(Constructor.java:513)
   [junit4]at 
sun.net.www.protocol.http.HttpURLConnection$6.run(HttpURLConnection.java:1491)
   [junit4]at java.security.AccessController.doPrivileged(Native 
Method)
   [junit4]at 
sun.net.www.protocol.http.HttpURLConnection.getChainedException(HttpURLConnection.java:1485)
   [junit4]at 
sun.net.www.protocol.http.HttpURLConnection.getInputStream(HttpURLConnection.java:1139)
   [junit4]at 
org.apache.solr.common.util.ContentStreamBase$URLStream.getStream(ContentStreamBase.java:87)
   [junit4]at 
org.apache.solr.common.util.ContentStreamTest.testURLStream(ContentStreamTest.java:93)
   [junit4]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
Method)
   [junit4]at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
   [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

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

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

--
[...truncated 16750 lines...]
   [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=228133864FC15184 -Dtests.locale=fr_BE 
-Dtests.timezone=America/Sitka -Dargs=-Dfile.encoding=Cp1252
   [junit4]   1 
   [junit4]   2
   [junit4] (@AfterClass output)
   [junit4]   2 60967 T2868 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=1083738034
   [junit4]   2 60967 T2868 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@c98bf3f
   [junit4]   2 60968 T2868 oasc.SolrCore.closeSearcher [collection1] Closing 
main searcher on request.
   [junit4]   2 60968 T2868 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=2,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=494,cumulative_deletesById=0,cumulative_deletesByQuery=1,cumulative_errors=0}
   [junit4]   2 60972 T2868 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
   [junit4]   2 61026 T2868 oasc.CoreContainer.shutdown Shutting down 
CoreContainer instance=500842135
   [junit4]   2 61026 T2868 oasc.SolrCore.close [collection1]  CLOSING 
SolrCore org.apache.solr.core.SolrCore@402dd57b
   [junit4]   2 61027 T2868 oasc.SolrCore.closeSearcher [collection1] Closing 
main searcher on request.
   [junit4]   2 61027 T2868 oasu.DirectUpdateHandler2.close closing 
DirectUpdateHandler2{commits=1,autocommits=0,soft 
autocommits=0,optimizes=0,rollbacks=0,expungeDeletes=0,docsPending=0,adds=0,deletesById=0,deletesByQuery=0,errors=0,cumulative_adds=0,cumulative_deletesById=0,cumulative_deletesByQuery=0,cumulative_errors=0}
   [junit4]   2 61029 T2868 oejsh.ContextHandler.doStop stopped 
o.e.j.s.ServletContextHandler{/solr,null}
   [junit4]   2 61096 T2868 oas.SolrTestCaseJ4.deleteCore ###deleteCore
   [junit4]   2 NOTE: test params are: codec=Lucene40, 
sim=RandomSimilarityProvider(queryNorm=false,coord=true): {}, locale=fr_BE, 
timezone=America/Sitka
   [junit4]   2 NOTE: Windows 7 6.1 amd64/Sun Microsystems Inc. 1.6.0_32 
(64-bit)/cpus=2,threads=1,free=160386400,total=211353600
   [junit4]   2 NOTE: All tests run in this JVM: [QueryElevationComponentTest, 
TestConfig, TestEnglishMinimalStemFilterFactory, TestSynonymMap, 
FieldAnalysisRequestHandlerTest, DisMaxRequestHandlerTest, 
TestElisionFilterFactory, TestSolrCoreProperties, CSVRequestHandlerTest, 
TestKStemFilterFactory, TestDictionaryCompoundWordTokenFilterFactory, 
AlternateDirectoryTest, TestDistributedSearch, TestPhraseSuggestions, 
TestCSVResponseWriter, TestSort, DistributedSpellCheckComponentTest, 
UUIDFieldTest, SolrPluginUtilsTest, CloudStateTest, SolrCmdDistributorTest, 
LoggingHandlerTest, TestKeepFilterFactory, TestFrenchMinimalStemFilterFactory, 
MinimalSchemaTest, TestGalicianStemFilterFactory, XmlUpdateRequestHandlerTest, 
ShowFileRequestHandlerTest, TestPorterStemFilterFactory, 
NotRequiredUniqueKeyTest, TestXIncludeConfig, JsonLoaderTest, 
TestSlowSynonymFilter, LegacyHTMLStripCharFilterTest, DebugComponentTest, 
TestChineseTokenizerFactory, PeerSyncTest, SignatureUpdateProcessorFactoryTest, 
TestBrazilianStemFilterFactory, DateMathParserTest, TermVectorComponentTest, 
TestGermanNormalizationFilterFactory, SampleTest, 
FieldMutatingUpdateProcessorTest, SuggesterWFSTTest, RequestHandlersTest, 
TestCSVLoader, TestLMDirichletSimilarityFactory, OutputWriterTest, 
TestDelimitedPayloadTokenFilterFactory,

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

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


-
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 # 14318 - Failure

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

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

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

Stack Trace:
java.lang.AssertionError: ERROR: SolrIndexSearcher opens=79 closes=78
at __randomizedtesting.SeedInfo.seed([4B9754F558775BB6]: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.GeneratedMethodAccessor13.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 10453 lines...]



-
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 #191

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


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

[jira] [Resolved] (SOLR-3446) PatternSyntaxException Crash from Unvalidated Regular Expression Usage

2012-05-24 Thread Hoss Man (JIRA)


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

Hoss Man resolved SOLR-3446.


   Resolution: Fixed
Fix Version/s: 4.0
 Assignee: Hoss Man


Eric: I'm not really a fan of the isRegex and regexError utilities you 
proposed in your patch, because they throw away info about the details of the 
exception, and require redundant calls to Pattern.compile in situations where 
it's known that Pattern.compile is going to fail.

But the crux of your bug report is spot on -- PatternTokenizerFactory was 
dealing with the pattern init param poorly, and should have been following the 
model used in PatternReplaceCharFilterFactory and PatternReplaceFilterFactory 
-- however even with those, the general plugin loading mechanism wasn't doing a 
very good job of drawing attention to where exactly the problem was.

So i've committed a fix that:
* refactors those three factories to use a common getPattern method in the 
base class
* improves AbstractPluginLoader to include the name of the plugin that had a 
problem (if known)

Committed revision 1342489.

thanks for opening the bug and drawing attention to this!


 PatternSyntaxException Crash from Unvalidated Regular Expression Usage
 --

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

 Attachments: SOLR-3446.patch, bug.patch


 Solr sometimes crashes with an unhelpful stack trace.  If the 
 PatternTokenizerFactory's pattern attribute is set to an invalid regular 
 expression, a PatternSyntaxException is thrown and Solr fails to start. The 
 PatternSyntaxException is not useful to users in diagnosing the error. I 
 think it would be better to report a detailed error message. The attached 
 patch makes this change.
 Note that the patch adds a small RegexUtil class with helper methods to 
 determine whether a String is a valid regular expression and to generate 
 error messages for invalid regular expressions. I feel that these helper 
 methods are more readable than catching the PatternSyntaxException. 
 Furthermore, they can be re-used if more bugs like this one are found.
 Steps to reproduce:
 # Patch in bug.patch
 #* Note that this sets PatternTokenizerFactory's pattern attribute to an 
 invalid regular expression.
 # Run 'ant run-example' from the solr folder
 # See exception in console output on startup:
 {code}
 Apr 3, 2012 2:07:29 PM org.apache.solr.common.SolrException log
 SEVERE: java.util.regex.PatternSyntaxException: Unclosed group near index 1
 (
  ^
at java.util.regex.Pattern.error(Pattern.java:1713)
at java.util.regex.Pattern.accept(Pattern.java:1571)
at java.util.regex.Pattern.group0(Pattern.java:2533)
at java.util.regex.Pattern.sequence(Pattern.java:1806)
at java.util.regex.Pattern.expr(Pattern.java:1752)
at java.util.regex.Pattern.compile(Pattern.java:1460)
at java.util.regex.Pattern.init(Pattern.java:1133)
at java.util.regex.Pattern.compile(Pattern.java:847)
at 
 org.apache.solr.analysis.PatternTokenizerFactory.init(PatternTokenizerFactory.java:90)
at org.apache.solr.schema.IndexSchema$5.init(IndexSchema.java:901)
at org.apache.solr.schema.IndexSchema$5.init(IndexSchema.java:890)
at 
 org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:148)
at 
 org.apache.solr.schema.IndexSchema.readAnalyzer(IndexSchema.java:910)
at org.apache.solr.schema.IndexSchema.access$100(IndexSchema.java:62)
at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:450)
at org.apache.solr.schema.IndexSchema$1.create(IndexSchema.java:435)
at 
 org.apache.solr.util.plugin.AbstractPluginLoader.load(AbstractPluginLoader.java:140)
at org.apache.solr.schema.IndexSchema.readSchema(IndexSchema.java:480)
at org.apache.solr.schema.IndexSchema.init(IndexSchema.java:125)
at org.apache.solr.core.CoreContainer.create(CoreContainer.java:461)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:316)
at org.apache.solr.core.CoreContainer.load(CoreContainer.java:207)
at 
 org.apache.solr.core.CoreContainer$Initializer.initialize(CoreContainer.java:130)
at 
 org.apache.solr.servlet.SolrDispatchFilter.init(SolrDispatchFilter.java:94)
at org.mortbay.jetty.servlet.FilterHolder.doStart(FilterHolder.java:97)
at 
 org.mortbay.component.AbstractLifeCycle.start(AbstractLifeCycle.java:50)
at 
 org.mortbay.jetty.servlet.ServletHandler.initialize(ServletHandler.java:713)
at

[jira] [Resolved] (LUCENE-4075) Crazy checkout paths break TestXPathEntityProcessor

2012-05-24 Thread Hoss Man (JIRA)


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

Hoss Man resolved LUCENE-4075.
--

   Resolution: Fixed
Fix Version/s: 4.0
 Assignee: Greg Bowyer

Committed revision 1342490.

Thanks Greg

 Crazy checkout paths break TestXPathEntityProcessor
 ---

 Key: LUCENE-4075
 URL: https://issues.apache.org/jira/browse/LUCENE-4075
 Project: Lucene - Java
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Greg Bowyer
Assignee: Greg Bowyer
 Fix For: 4.0

 Attachments: LUCENE-4075-TestXPathEntityProcessor-WierdPath-Fix.patch


 Same as a bug I raised for javadoc generation, my build.xml is the same as 
 upstream, the problem is my checkout path looks like this
 /home/buildserver/workspace/builds/{search-engineering}solr-lucene{trunk}
 This means that the prepare-webpages target gets its paths in the buildpaths 
 variable as a pipe separated list like so
 /home/buildserver/workspace/builds/{search-engineering}solr-lucene{trunk}/lucene/analysis/common/build.xml|/home/buildserver/workspace/builds/{search-engineering}solr-lucene{trunk}/lucene/analysis/icu/build.xml|...(and
  so on)
 Attached is a patch that makes TestXPathEntityProcessor use a url rather than 
 the filesystem path that makes XPath / xml happier with crazy path names

--
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 #117

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

Changes:

[hossman] LUCENE-4075: Cleaner path usage in TestXPathEntityProcessor

[hossman] SOLR-3446: Better errors when PatternTokenizerFactory is configured 
with an invalid pattern, and include the 'name' whenever possible in plugin 
init error messages.

--
[...truncated 17563 lines...]
   [junit4]   2 48476 T3034 oasc.RequestHandlers.initHandlersFromConfig 
created /mlt: solr.MoreLikeThisHandler
   [junit4]   2 48478 T3034 oasc.RequestHandlers.initHandlersFromConfig 
created /debug/dump: solr.DumpRequestHandler
   [junit4]   2 48479 T3034 oashl.XMLLoader.init xsltCacheLifetimeSeconds=60
   [junit4]   2 48480 T3034 oasc.SolrCore.initDeprecatedSupport WARNING 
solrconfig.xml uses deprecated admin/gettableFiles, Please update your config 
to use the ShowFileRequestHandler.
   [junit4]   2 48483 T3034 oasc.SolrCore.initDeprecatedSupport WARNING adding 
ShowFileRequestHandler with hidden files: [SOLRCONFIG-HIGHLIGHT.XML, 
SCHEMA-REQUIRED-FIELDS.XML, SCHEMA-REPLICATION2.XML, SCHEMA-MINIMAL.XML, 
BAD-SCHEMA-DUP-DYNAMICFIELD.XML, SOLRCONFIG-CACHING.XML, 
SOLRCONFIG-REPEATER.XML, CURRENCY.XML, BAD-SCHEMA-NONTEXT-ANALYZER.XML, 
SOLRCONFIG-MERGEPOLICY.XML, SOLRCONFIG-TLOG.XML, SOLRCONFIG-MASTER.XML, 
SCHEMA11.XML, SOLRCONFIG-BASIC.XML, DA_COMPOUNDDICTIONARY.TXT, 
SCHEMA-COPYFIELD-TEST.XML, SOLRCONFIG-SLAVE.XML, ELEVATE.XML, 
SOLRCONFIG-PROPINJECT-INDEXDEFAULT.XML, SCHEMA-IB.XML, 
SOLRCONFIG-QUERYSENDER.XML, SCHEMA-REPLICATION1.XML, DA_UTF8.XML, 
HYPHENATION.DTD, SOLRCONFIG-ENABLEPLUGIN.XML, STEMDICT.TXT, 
SCHEMA-PHRASESUGGEST.XML, HUNSPELL-TEST.AFF, STOPTYPES-1.TXT, 
STOPWORDSWRONGENCODING.TXT, SCHEMA-NUMERIC.XML, SOLRCONFIG-TRANSFORMERS.XML, 
SOLRCONFIG-PROPINJECT.XML, BAD-SCHEMA-NOT-INDEXED-BUT-TF.XML, 
SOLRCONFIG-SIMPLELOCK.XML, WDFTYPES.TXT, STOPTYPES-2.TXT, SCHEMA-REVERSED.XML, 
SOLRCONFIG-SPELLCHECKCOMPONENT.XML, SCHEMA-DFR.XML, 
SOLRCONFIG-PHRASESUGGEST.XML, BAD-SCHEMA-NOT-INDEXED-BUT-POS.XML, KEEP-1.TXT, 
OPEN-EXCHANGE-RATES.JSON, STOPWITHBOM.TXT, SCHEMA-BINARYFIELD.XML, 
SOLRCONFIG-SPELLCHECKER.XML, SOLRCONFIG-UPDATE-PROCESSOR-CHAINS.XML, 
BAD-SCHEMA-OMIT-TF-BUT-NOT-POS.XML, BAD-SCHEMA-DUP-FIELDTYPE.XML, 
SOLRCONFIG-MASTER1.XML, SYNONYMS.TXT, SCHEMA.XML, SCHEMA_CODEC.XML, 
SOLRCONFIG-SOLR-749.XML, SOLRCONFIG-MASTER1-KEEPONEBACKUP.XML, STOP-2.TXT, 
SOLRCONFIG-FUNCTIONQUERY.XML, SCHEMA-LMDIRICHLET.XML, SOLRCONFIG-TERMINDEX.XML, 
SOLRCONFIG-ELEVATE.XML, STOPWORDS.TXT, SCHEMA-FOLDING.XML, 
SCHEMA-STOP-KEEP.XML, BAD-SCHEMA-NOT-INDEXED-BUT-NORMS.XML, 
SOLRCONFIG-SOLCOREPROPERTIES.XML, STOP-1.TXT, SOLRCONFIG-MASTER2.XML, 
SCHEMA-SPELLCHECKER.XML, SOLRCONFIG-LAZYWRITER.XML, 
SCHEMA-LUCENEMATCHVERSION.XML, BAD-MP-SOLRCONFIG.XML, FRENCHARTICLES.TXT, 
SCHEMA15.XML, SOLRCONFIG-REQHANDLER.INCL, SCHEMASURROUND.XML, 
SCHEMA-COLLATEFILTER.XML, SOLRCONFIG-MASTER3.XML, HUNSPELL-TEST.DIC, 
SOLRCONFIG-XINCLUDE.XML, SOLRCONFIG-DELPOLICY1.XML, SOLRCONFIG-SLAVE1.XML, 
SCHEMA-SIM.XML, SCHEMA-COLLATE.XML, STOP-SNOWBALL.TXT, PROTWORDS.TXT, 
SCHEMA-TRIE.XML, SOLRCONFIG_CODEC.XML, SCHEMA-TFIDF.XML, 
SCHEMA-LMJELINEKMERCER.XML, PHRASESUGGEST.TXT, 
SOLRCONFIG-BASIC-LUCENEVERSION31.XML, OLD_SYNONYMS.TXT, 
SOLRCONFIG-DELPOLICY2.XML, XSLT, SOLRCONFIG-NATIVELOCK.XML, 
BAD-SCHEMA-DUP-FIELD.XML, SOLRCONFIG-NOCACHE.XML, SCHEMA-BM25.XML, 
SOLRCONFIG-ALTDIRECTORY.XML, SOLRCONFIG-QUERYSENDER-NOQUERY.XML, 
COMPOUNDDICTIONARY.TXT, SOLRCONFIG_PERF.XML, 
SCHEMA-NOT-REQUIRED-UNIQUE-KEY.XML, KEEP-2.TXT, SCHEMA12.XML, 
MAPPING-ISOLATIN1ACCENT.TXT, BAD_SOLRCONFIG.XML, 
BAD-SCHEMA-EXTERNAL-FILEFIELD.XML]
   [junit4]   2 48486 T3034 oass.SolrIndexSearcher.init Opening 
Searcher@1c8a88cb main
   [junit4]   2 48486 T3034 oass.SolrIndexSearcher.init WARNING WARNING: 
Directory impl does not support setting indexDir: 
org.apache.lucene.store.MockDirectoryWrapper
   [junit4]   2 48487 T3034 oasu.CommitTracker.init Hard AutoCommit: disabled
   [junit4]   2 48487 T3034 oasu.CommitTracker.init Soft AutoCommit: disabled
   [junit4]   2 48487 T3034 oashc.SpellCheckComponent.inform Initializing 
spell checkers
   [junit4]   2 48497 T3034 oass.DirectSolrSpellChecker.init init: 
{name=direct,classname=DirectSolrSpellChecker,field=lowerfilt,minQueryLength=3}
   [junit4]   2 48546 T3034 oashc.HttpShardHandlerFactory.getParameter Setting 
socketTimeout to: 0
   [junit4]   2 48546 T3034 oashc.HttpShardHandlerFactory.getParameter Setting 
urlScheme to: http://
   [junit4]   2 48546 T3034 oashc.HttpShardHandlerFactory.getParameter Setting 
connTimeout to: 0
   [junit4]   2 48546 T3034 oashc.HttpShardHandlerFactory.getParameter Setting 
maxConnectionsPerHost to: 20
   [junit4]   2 48547 T3034 oashc.HttpShardHandlerFactory.getParameter Setting 
corePoolSize to: 0
   [junit4]   2 48547 T3034 oashc.HttpShardHandlerFactory.getParameter Setting 
maximumPoolSize to: 2147483647
   [junit4]   2 48547 T3034 oashc.HttpShardHandlerFactory.getParameter

[jira] [Commented] (SOLR-3486) The memory size of Solr caches should be configurable

2012-05-24 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on SOLR-3486:


This is an awesome idea.  SOLR-3393 is a new implementation of LFUCache, I'll 
have to figure out how to include this, unless you want to give it a try.

 The memory size of Solr caches should be configurable
 -

 Key: SOLR-3486
 URL: https://issues.apache.org/jira/browse/SOLR-3486
 Project: Solr
  Issue Type: Improvement
  Components: search
Reporter: Adrien Grand
Priority: Minor
 Attachments: SOLR-3486.patch


 It is currently possible to configure the sizes of Solr caches based on the 
 number of entries of the cache. The problem is that the memory size of cached 
 values may vary a lot over time (depending on IndexReader.maxDoc and the 
 queries that are run) although the JVM heap size does not.
 Having a configurable max size in bytes would also help optimize cache 
 utilization, making it possible to store more values provided that they have 
 a small memory footprint.

--
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 #118