Re: jar error while trying to build
On Tue, 18 Sep 2012, Mohamed Lrhazi wrote:
Hello,
I am trying to build pylucene on a redhat ent 6.1. the make fails with
an error pasted bellow.
Any hints appreciated.
Your Makefile seems to be broken in a way that --jar somewhere became
just jar and it's downhill from there.
jar lucene-java-3.6.1/lucene/build/core/lucene-core-3.6.1.jar --jar
Andi..
Thanks a lot,
Mohamed.
cd lucene-java-3.6.1/lucene; (/opt/ant/bin/ant ivy-fail ||
/opt/ant/bin/ant ivy-bootstrap)
Buildfile: /home/ml623/pylucene-3.6.1-2/lucene-java-3.6.1/lucene/build.xml
ivy-fail:
BUILD SUCCESSFUL
Total time: 0 seconds
ICU not installed
jar lucene-java-3.6.1/lucene/build/core/lucene-core-3.6.1.jar --jar
lucene-java-3.6.1/lucene/build/contrib/analyzers/common/lucene-analyzers-3.6.1.jar
--jar lucene-java-3.6.1/lucene/build/contrib/memory/lucene-memory-3.6.1.jar
--jar lucene-java-3.6.1/lucene/build/contrib/highlighter/lucene-highlighter
-3.6.1.jar --jar build/jar/extensions.jar --jar
lucene-java-3.6.1/lucene/build/contrib/queries/lucene-queries-3.6.1.jar
--jar lucene-java-3.6.1/lucene/
build/contrib/grouping/lucene-grouping-3.6.1.jar --jar
lucene-java-3.6.1/lucene/build/contrib/join/lucene-join-3.6.1.jar
--jar lucene-java-3.6.1/lucene
/build/contrib/facet/lucene-facet-3.6.1.jar --jar
lucene-java-3.6.1/lucene/build/contrib/spellchecker/lucene-spellchecker-3.6.1.jar
--package java.lan
g java.lang.System java.lang.Runtime java.lang.IllegalStateException
java.lang.IndexOutOfBoundsException --package java.util
java.util.Arrays java.util
.HashMap java.util.HashSet java.util.NoSuchElementException
java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator
--package java.util.regex --package java.io java.io.StringReader
java.io.InputStreamReader java.io.FileInputStream --exclude
org.apache.lucene.queryParser.Token --exclude
org.apache.lucene.queryParser.TokenMgrError --exclude
org.apache.lucene.queryParser.QueryParserTokenManager --exclude
org.apache.lucene.queryParser.ParseException --exclude
org.apache.lucene.queryParser.CharStream --exclude
org.apache.lucene.search.regex.JakartaRegexpCapabilities --exclude
org.apache.regexp.RegexpTunnel --exclude
org.apache.lucene.analysis.cn.smart.AnalyzerProfile --python lucene
--mapping org.apache.lucene.document.Document
'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping
java.util.Properties
'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence
java.util.AbstractList 'size:()I' 'get:(I)Ljava/lang/Object;' --rename
org.apache.lucene.search.highlight.SpanScorer=HighlighterSpanScorer
--rename org.apache.lucene.search.highlight.Scorer=HighlighterScorer
--rename org.apache.lucene.search.spell.Dictionary=SpellDictionary
--rename org.apache.lucene.search.suggest.fst.Sort=SuggestSort
--rename org.apache.lucene.store.DataInput=StoreDataInput --rename
org.apache.lucene.store.DataOutput=StoreDataOutput --rename
org.tartarus.snowball.ext.DutchStemmer=DutchPorterStemmer --rename
org.tartarus.snowball.ext.FrenchStemmer=FrenchPorterStemmer --rename
org.tartarus.snowball.ext.GermanStemmer=GermanPorterStemmer --rename
org.tartarus.snowball.ext.PortugueseStemmer=PortuguesePorterStemmer
--version 3.6.1 --module python/collections.py --module
python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py
--module python/ICUTransformFilter.py --files --build
Illegal option: l
Usage: jar {ctxui}[vfm0Me] [jar-file] [manifest-file] [entry-point]
[-C dir] files ...
Options:
-c create new archive
-t list table of contents for archive
...
[jira] [Commented] (SOLR-3846) TestReplicationHandler.test always (?) takes many minutes on OS X (lion)
[
https://issues.apache.org/jira/browse/SOLR-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457625#comment-13457625
]
Uwe Schindler commented on SOLR-3846:
-
+1, It is a great improvement! Thanks for testing. I also ran all tests on
windows locally and they successfully passed!
*For another issue an improvement:* _In my dreams last night_ I found a very
good solution for the problem with timeouting connections to IP addresses of
dead servers (like we have seen in the above 2 tests). My idea how to solve
this completely predictive (means it works on every computer, although firewall
settings may delay execution,...):
We already have a security manager and policy. The idea would be to also
implement checkConnect() and checkResolve() for this custom manager, which is
called on every connect. This method checks for a set of default dead servers
(would work with ip adresses, or fake host names): If it gets called with such
an address, it could throw IOException (like a SocketConnectException) so make
the fail predcicatable. The underlying O/S's network layer is then never
called, so no timeouts can occur. As SecurityManager cannot throw checked
exceptions, I would use:
{code:java}Rethrow.rethrow(new IOException(Emulated network failure));{code}
inside the SecurityManager.
TestReplicationHandler.test always (?) takes many minutes on OS X (lion)
Key: SOLR-3846
URL: https://issues.apache.org/jira/browse/SOLR-3846
Project: Solr
Issue Type: Improvement
Components: Build
Affects Versions: 4.0-BETA, 5.0
Environment: OS X (Lion). Apparently (see Yonik's notes) this does
NOT happen on other op systems.
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
Solr trunk and 4.x from 16-Sep, but it's been happening for a couple of weeks
at least.
Reporter: Erick Erickson
Assignee: Erick Erickson
Fix For: 4.0, 5.0
Attachments: SOLR-3846.patch, SOLR-3846.patch, SOLR-3846.patch,
SOLR-3846.patch, SOLR-3846.patch, stacks.txt
Here's the seed was using, but this is apparently unnecessary:
JUnit4 says ¡Hola! Master seed: 6785BB3284A15298
_eventually_ it seems to complete, but it takes many minutes, for instance
this was reported once, but I usually lose patience and ctrl-c out:
{code}
[junit4:junit4] Completed on J2 in 2449.62s, 1 test
[junit4:junit4]
[junit4:junit4] JVM J0: 1.21 .. 266.67 = 265.47s
[junit4:junit4] JVM J1: 1.21 .. 238.33 = 237.12s
[junit4:junit4] JVM J2: 1.21 .. 2538.60 = 2537.39s
[junit4:junit4] JVM J3: 0.97 .. 267.37 = 266.40s
[junit4:junit4] Execution time total: 42 minutes 18 seconds
{code}
and a lot of lines like:
HEARTBEAT J2: 2012-09-16T17:38:38, no events in: 187s, approx. at:
TestReplicationHandler.test
Yonik reports that he can make this happen 100% of the time on OS X/Lion,
which squares with my experience as I recall. Yonik also reports...
On my linux box (built in '09, PhenomII, HDD) the test takes 50-55 sec.
On my kids old windows box ('08, athlon64, HDD, Win7) the test takes 88-95
sec.
On my mac it always takes forever, and I see loops of stuff like this:
{code}
SEVERE Master at: http://localhost:62803/solr is not available. Index
fetch failed. Exception:
org.apache.solr.client.solrj.SolrServerException: Server refused
connection at: http://localhost:62803/solr
[junit4:junit4] 2 52751 T219 C17 UPDATE [collection1] webapp=/solr
path=/update params={wt=javabinversion=2} {add=[150]} 0 0
[junit4:junit4] 2 52755 T219 C17 UPDATE [collection1] webapp=/solr
path=/update params={wt=javabinversion=2} {add=[151]} 0 0
[junit4:junit4] 2 62758 T215 oash.SnapPuller.fetchLatestIndex
SEVERE Master at: http://localhost:62803/solr is not available. Index
fetch failed. Exception:
{code}
And I'm s happy it's not happening to others and just being swept under
the rug, restores my faith. I should have known better ;)
See the discussion on the dev list labeled being a good citizen is hard when
you can't successfully run tests for more context.
I don't know how much time I'll have to dive in to it but I'll certainly be
happy to test anyone's patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3846) TestReplicationHandler.test always (?) takes many minutes on OS X (lion)
[
https://issues.apache.org/jira/browse/SOLR-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457628#comment-13457628
]
Uwe Schindler commented on SOLR-3846:
-
The blackhole problem could also be solved: If all started Jetties register
themselves at LTC (like the MocjDirWrappers), this security manager could also
keep track of used port numbers and make the no longer actoive ones fail early!
TestReplicationHandler.test always (?) takes many minutes on OS X (lion)
Key: SOLR-3846
URL: https://issues.apache.org/jira/browse/SOLR-3846
Project: Solr
Issue Type: Improvement
Components: Build
Affects Versions: 4.0-BETA, 5.0
Environment: OS X (Lion). Apparently (see Yonik's notes) this does
NOT happen on other op systems.
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
Solr trunk and 4.x from 16-Sep, but it's been happening for a couple of weeks
at least.
Reporter: Erick Erickson
Assignee: Erick Erickson
Fix For: 4.0, 5.0
Attachments: SOLR-3846.patch, SOLR-3846.patch, SOLR-3846.patch,
SOLR-3846.patch, SOLR-3846.patch, stacks.txt
Here's the seed was using, but this is apparently unnecessary:
JUnit4 says ¡Hola! Master seed: 6785BB3284A15298
_eventually_ it seems to complete, but it takes many minutes, for instance
this was reported once, but I usually lose patience and ctrl-c out:
{code}
[junit4:junit4] Completed on J2 in 2449.62s, 1 test
[junit4:junit4]
[junit4:junit4] JVM J0: 1.21 .. 266.67 = 265.47s
[junit4:junit4] JVM J1: 1.21 .. 238.33 = 237.12s
[junit4:junit4] JVM J2: 1.21 .. 2538.60 = 2537.39s
[junit4:junit4] JVM J3: 0.97 .. 267.37 = 266.40s
[junit4:junit4] Execution time total: 42 minutes 18 seconds
{code}
and a lot of lines like:
HEARTBEAT J2: 2012-09-16T17:38:38, no events in: 187s, approx. at:
TestReplicationHandler.test
Yonik reports that he can make this happen 100% of the time on OS X/Lion,
which squares with my experience as I recall. Yonik also reports...
On my linux box (built in '09, PhenomII, HDD) the test takes 50-55 sec.
On my kids old windows box ('08, athlon64, HDD, Win7) the test takes 88-95
sec.
On my mac it always takes forever, and I see loops of stuff like this:
{code}
SEVERE Master at: http://localhost:62803/solr is not available. Index
fetch failed. Exception:
org.apache.solr.client.solrj.SolrServerException: Server refused
connection at: http://localhost:62803/solr
[junit4:junit4] 2 52751 T219 C17 UPDATE [collection1] webapp=/solr
path=/update params={wt=javabinversion=2} {add=[150]} 0 0
[junit4:junit4] 2 52755 T219 C17 UPDATE [collection1] webapp=/solr
path=/update params={wt=javabinversion=2} {add=[151]} 0 0
[junit4:junit4] 2 62758 T215 oash.SnapPuller.fetchLatestIndex
SEVERE Master at: http://localhost:62803/solr is not available. Index
fetch failed. Exception:
{code}
And I'm s happy it's not happening to others and just being swept under
the rug, restores my faith. I should have known better ;)
See the discussion on the dev list labeled being a good citizen is hard when
you can't successfully run tests for more context.
I don't know how much time I'll have to dive in to it but I'll certainly be
happy to test anyone's patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4405) java.lang.NumberFormatException: For input string: 4g3 (1)
Radhakrishna Bhat created LUCENE-4405: - Summary: java.lang.NumberFormatException: For input string: 4g3 (1) Key: LUCENE-4405 URL: https://issues.apache.org/jira/browse/LUCENE-4405 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 3.5 Environment: Windows 7 64 bit JDK Reporter: Radhakrishna Bhat When trying to instantiate IndexWriter, I get this exception. I have no other clues on why this might happen. Caused by: java.lang.NumberFormatException: For input string: 4g3 (1) at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Long.parseLong(Long.java:419) at org.apache.lucene.index.SegmentInfos.generationFromSegmentsFileName(SegmentInfos.java:214) at org.apache.lucene.index.SegmentInfos.getCurrentSegmentGeneration(SegmentInfos.java:149) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:626) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:575) at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:346) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1115) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4405) java.lang.NumberFormatException: For input string: 4g3 (1)
[ https://issues.apache.org/jira/browse/LUCENE-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457647#comment-13457647 ] Uwe Schindler commented on LUCENE-4405: --- Hi Radhakrishna, the reason for this error is generally one of the following: - You try to create a new index in a non-empty directory. If one of the files looks like a index file name it is taken into account. Use an empty directory for new indexes. - You try to open an existing index, where non-lucene files are placed in it. The above filename looks like a cloned file (e.g. by pressing Ctrl-C, Ctrl-V in your file manager) causing this Exception. Clean up your index directory by removing the file that contains the above pattern from the Exception message - or recreate the index. File names are part of the Lucene index structure, so foreign names violate the file format (in our case it is more a directory format). I would say this is wont fix for Lucene 3.x, but in Lucene trunk/4.x we should revisit this code and maybe rethrow the NumberFormatException as CorruptIndexException with the full file name and explanation (the above message only shows part of the file). java.lang.NumberFormatException: For input string: 4g3 (1) Key: LUCENE-4405 URL: https://issues.apache.org/jira/browse/LUCENE-4405 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 3.5 Environment: Windows 7 64 bit JDK Reporter: Radhakrishna Bhat When trying to instantiate IndexWriter, I get this exception. I have no other clues on why this might happen. Caused by: java.lang.NumberFormatException: For input string: 4g3 (1) at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Long.parseLong(Long.java:419) at org.apache.lucene.index.SegmentInfos.generationFromSegmentsFileName(SegmentInfos.java:214) at org.apache.lucene.index.SegmentInfos.getCurrentSegmentGeneration(SegmentInfos.java:149) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:626) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:575) at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:346) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1115) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError
[
https://issues.apache.org/jira/browse/SOLR-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss reassigned SOLR-3849:
-
Assignee: Dawid Weiss (was: Hoss Man)
ScriptEngineTest failure RE system properties and ThreadLeakError
-
Key: SOLR-3849
URL: https://issues.apache.org/jira/browse/SOLR-3849
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 5.0
Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Dawid Weiss
100% reproducible for me:
solr$ ant test -Dtestcase=ScriptEngineTest
{noformat}
[junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4]
[junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
[junit4:junit4] OK 0.17s | ScriptEngineTest.testPut
[junit4:junit4] OK 0.02s | ScriptEngineTest.testEvalReader
[junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
[junit4:junit4] Assumption #1: got: [null], expected: each not null
[junit4:junit4] OK 0.01s | ScriptEngineTest.testEvalText
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByExtension
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByName
[junit4:junit4] 2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING
Will linger awaiting termination of 2 leaked thread(s).
[junit4:junit4] 2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1
thread leaked from SUITE scope at
org.apache.solr.update.processor.ScriptEngineTest:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll
Starting to interrupt leaked threads:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE
There are still zombie threads that couldn't be terminated:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 NOTE: test params are: codec=SimpleText,
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR,
timezone=America/Edmonton
[junit4:junit4] 2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
[junit4:junit4] 2 NOTE: All tests run in this JVM: [ScriptEngineTest]
[junit4:junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true
-Dtests.locale=es_PR -Dtests.timezone=America/Edmonton
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 0.00s | ScriptEngineTest (suite)
[junit4:junit4] Throwable #1: java.lang.AssertionError: System
properties invariant violated.
[junit4:junit4] New keys:
[junit4:junit4] sun.awt.enableExtraMouseButtons=true
[junit4:junit4] sun.font.fontmanager=sun.font.CFontManager
[junit4:junit4]
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4] at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4] at java.lang.Thread.run(Thread.java:722)
[junit4:junit4] Throwable #2:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from
SUITE scope at org.apache.solr.update.processor.ScriptEngineTest:
[junit4:junit4]1) Thread[id=11,
[jira] [Commented] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError
[
https://issues.apache.org/jira/browse/SOLR-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457651#comment-13457651
]
Dawid Weiss commented on SOLR-3849:
---
I'll take over, this seems like an unknown system thread (AppKit Thread)
probably forked by AWT. Why is AWT forked with this test, I'll have to take a
look.
ScriptEngineTest failure RE system properties and ThreadLeakError
-
Key: SOLR-3849
URL: https://issues.apache.org/jira/browse/SOLR-3849
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 5.0
Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Dawid Weiss
100% reproducible for me:
solr$ ant test -Dtestcase=ScriptEngineTest
{noformat}
[junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4]
[junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
[junit4:junit4] OK 0.17s | ScriptEngineTest.testPut
[junit4:junit4] OK 0.02s | ScriptEngineTest.testEvalReader
[junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
[junit4:junit4] Assumption #1: got: [null], expected: each not null
[junit4:junit4] OK 0.01s | ScriptEngineTest.testEvalText
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByExtension
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByName
[junit4:junit4] 2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING
Will linger awaiting termination of 2 leaked thread(s).
[junit4:junit4] 2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1
thread leaked from SUITE scope at
org.apache.solr.update.processor.ScriptEngineTest:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll
Starting to interrupt leaked threads:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE
There are still zombie threads that couldn't be terminated:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 NOTE: test params are: codec=SimpleText,
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR,
timezone=America/Edmonton
[junit4:junit4] 2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
[junit4:junit4] 2 NOTE: All tests run in this JVM: [ScriptEngineTest]
[junit4:junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true
-Dtests.locale=es_PR -Dtests.timezone=America/Edmonton
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 0.00s | ScriptEngineTest (suite)
[junit4:junit4] Throwable #1: java.lang.AssertionError: System
properties invariant violated.
[junit4:junit4] New keys:
[junit4:junit4] sun.awt.enableExtraMouseButtons=true
[junit4:junit4] sun.font.fontmanager=sun.font.CFontManager
[junit4:junit4]
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4] at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4] at java.lang.Thread.run(Thread.java:722)
[junit4:junit4] Throwable #2:
[jira] [Commented] (LUCENE-4405) java.lang.NumberFormatException: For input string: 4g3 (1)
[ https://issues.apache.org/jira/browse/LUCENE-4405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457652#comment-13457652 ] Radhakrishna Bhat commented on LUCENE-4405: --- Thank you Uwe. I will clean my index directory and try again. java.lang.NumberFormatException: For input string: 4g3 (1) Key: LUCENE-4405 URL: https://issues.apache.org/jira/browse/LUCENE-4405 Project: Lucene - Core Issue Type: Bug Components: core/index Affects Versions: 3.5 Environment: Windows 7 64 bit JDK Reporter: Radhakrishna Bhat When trying to instantiate IndexWriter, I get this exception. I have no other clues on why this might happen. Caused by: java.lang.NumberFormatException: For input string: 4g3 (1) at java.lang.NumberFormatException.forInputString(NumberFormatException.java:48) at java.lang.Long.parseLong(Long.java:419) at org.apache.lucene.index.SegmentInfos.generationFromSegmentsFileName(SegmentInfos.java:214) at org.apache.lucene.index.SegmentInfos.getCurrentSegmentGeneration(SegmentInfos.java:149) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:626) at org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:575) at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:346) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1115) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.6.0_35) - Build # 818 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/818/
Java: 64bit/jdk1.6.0_35 -XX:+UseConcMarkSweepGC
1 tests failed.
FAILED: junit.framework.TestSuite.org.apache.solr.util.TestNumberUtils
Error Message:
Clean up static fields (in @AfterClass?), your test seems to hang on to
approximately 12,082,960 bytes (threshold is 10,485,760): - 12,082,520 bytes,
static java.util.Random org.apache.solr.util.TestNumberUtils.rng - 168 bytes,
static double[] org.apache.solr.util.TestNumberUtils.dspecial - 144 bytes,
static long[] org.apache.solr.util.TestNumberUtils.lspecial - 80 bytes,
static float[] org.apache.solr.util.TestNumberUtils.fspecial - 48 bytes,
static int[] org.apache.solr.util.TestNumberUtils.special
Stack Trace:
junit.framework.AssertionFailedError: Clean up static fields (in @AfterClass?),
your test seems to hang on to approximately 12,082,960 bytes (threshold is
10,485,760):
- 12,082,520 bytes, static java.util.Random
org.apache.solr.util.TestNumberUtils.rng
- 168 bytes, static double[] org.apache.solr.util.TestNumberUtils.dspecial
- 144 bytes, static long[] org.apache.solr.util.TestNumberUtils.lspecial
- 80 bytes, static float[] org.apache.solr.util.TestNumberUtils.fspecial
- 48 bytes, static int[] org.apache.solr.util.TestNumberUtils.special
at __randomizedtesting.SeedInfo.seed([43A58F90C72F1DD]:0)
at
com.carrotsearch.randomizedtesting.rules.StaticFieldsInvariantRule$1.afterAlways(StaticFieldsInvariantRule.java:119)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:662)
Build Log:
[...truncated 7172 lines...]
[junit4:junit4] Suite: org.apache.solr.util.TestNumberUtils
[junit4:junit4] 2 NOTE: test params are: codec=Lucene40: {},
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=hr,
timezone=Asia/Dacca
[junit4:junit4] 2 NOTE: Windows 7 6.1 amd64/Sun Microsystems Inc. 1.6.0_35
(64-bit)/cpus=2,threads=1,free=44755656,total=109666304
[junit4:junit4] 2 NOTE: All tests run in this JVM: [TestConfig,
TestDocumentBuilder, TestDistributedSearch, NoCacheHeaderTest, HighlighterTest,
StandardRequestHandlerTest, TestReload, DirectSolrConnectionTest,
TestWordDelimiterFilterFactory, TestBinaryField, TestStressRecovery,
IndexSchemaTest, UpdateRequestProcessorFactoryTest, TestWriterPerf,
TestSearchPerf, SolrCoreTest, SuggesterTSTTest, TestQuerySenderNoQuery,
MinimalSchemaTest, DateMathParserTest, SolrCmdDistributorTest,
ShowFileRequestHandlerTest, TestFiltering, SuggesterWFSTTest,
TestRandomFaceting, BasicDistributedZkTest, TestPropInject,
TestReversedWildcardFilterFactory, TestGroupingSearch, RequestHandlersTest,
UUIDFieldTest, UpdateParamsTest, ZkSolrClientTest, QueryEqualityTest,
DocumentAnalysisRequestHandlerTest, TimeZoneUtilsTest,
DefaultValueUpdateProcessorTest, RAMDirectoryFactoryTest,
TestFoldingMultitermQuery, SampleTest, TestCodecSupport, TestLFUCache,
TestLMDirichletSimilarityFactory, TestIndexSearcher, DirectUpdateHandlerTest,
ZkControllerTest, TestMultiCoreConfBootstrap, IndexReaderFactoryTest,
TestMergePolicyConfig, TestUtils, ReturnFieldsTest, SpellCheckCollatorTest,
TestSurroundQueryParser, TestQueryTypes, ResourceLoaderTest,
TestPHPSerializedResponseWriter, ScriptEngineTest, PrimitiveFieldTypeTest,
TestExtendedDismaxParser, NumericFieldsTest, PolyFieldTest,
DistributedTermsComponentTest, BasicFunctionalityTest, AlternateDirectoryTest,
AutoCommitTest, SoftAutoCommitTest, FieldMutatingUpdateProcessorTest,
BadIndexSchemaTest, OpenExchangeRatesOrgProviderTest, PingRequestHandlerTest,
DocumentBuilderTest, TestLRUCache, SearchHandlerTest, ConvertedLegacyTest,
TestUpdate, TestFastOutputStream, TestStressLucene, TestJmxMonitoredMap,
PluginInfoTest, URLClassifyProcessorTest, TestSystemIdResolver,
TestRealTimeGet, XsltUpdateRequestHandlerTest, TestBinaryResponseWriter,
TestSolrDeletionPolicy1, BinaryUpdateRequestHandlerTest, TestDocSet,
TermsComponentTest, TestCollationField, CopyFieldTest, SolrRequestParserTest,
BadComponentTest, TestLuceneMatchVersion, TestQuerySenderListener,
NotRequiredUniqueKeyTest, BasicDistributedZk2Test, TestRTGBase, TestNumberUtils]
[junit4:junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestNumberUtils
[jira] [Commented] (SOLR-3766) A test group and build plan for known unstable tests
[
https://issues.apache.org/jira/browse/SOLR-3766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457658#comment-13457658
]
Dawid Weiss commented on SOLR-3766:
---
bq. What do you think of inverting the notion? That is, run the @UnstableTest
tests by default and allow them to be disabled explicitly? Perhaps disable them
for the precommit step?
It's what it used to be, check out the diff from my latest commit. I even
marked some of the tests with that annotation. But those annotations that I
added have been removed, the tests still fail and I'm just tired of arguing
about the whole subject. I'll probably do what Uwe said -- just not run Solr
tests at all.
A test group and build plan for known unstable tests
Key: SOLR-3766
URL: https://issues.apache.org/jira/browse/SOLR-3766
Project: Solr
Issue Type: Task
Reporter: Dawid Weiss
Priority: Minor
As discussed on the mailing list and suggested by Hoss:
{code}
1) slap a special @UnstableTest annotation on them
2) set up a new jenkins job that *only* runs these @UnstableTest jobs
3) configure this new jenkins job to not send any email
{code}
Point 1 is trivial, 2 I have filed an issue for in the runner --
https://github.com/carrotsearch/randomizedtesting/issues/122
that I will take care of shortly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.6.0_35) - Build # 818 - Failure!
I'll take a look.
D.
On Tue, Sep 18, 2012 at 9:07 AM, Policeman Jenkins Server
jenk...@sd-datasolutions.de wrote:
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/818/
Java: 64bit/jdk1.6.0_35 -XX:+UseConcMarkSweepGC
1 tests failed.
FAILED: junit.framework.TestSuite.org.apache.solr.util.TestNumberUtils
Error Message:
Clean up static fields (in @AfterClass?), your test seems to hang on to
approximately 12,082,960 bytes (threshold is 10,485,760): - 12,082,520
bytes, static java.util.Random org.apache.solr.util.TestNumberUtils.rng -
168 bytes, static double[] org.apache.solr.util.TestNumberUtils.dspecial -
144 bytes, static long[] org.apache.solr.util.TestNumberUtils.lspecial - 80
bytes, static float[] org.apache.solr.util.TestNumberUtils.fspecial - 48
bytes, static int[] org.apache.solr.util.TestNumberUtils.special
Stack Trace:
junit.framework.AssertionFailedError: Clean up static fields (in
@AfterClass?), your test seems to hang on to approximately 12,082,960 bytes
(threshold is 10,485,760):
- 12,082,520 bytes, static java.util.Random
org.apache.solr.util.TestNumberUtils.rng
- 168 bytes, static double[] org.apache.solr.util.TestNumberUtils.dspecial
- 144 bytes, static long[] org.apache.solr.util.TestNumberUtils.lspecial
- 80 bytes, static float[] org.apache.solr.util.TestNumberUtils.fspecial
- 48 bytes, static int[] org.apache.solr.util.TestNumberUtils.special
at __randomizedtesting.SeedInfo.seed([43A58F90C72F1DD]:0)
at
com.carrotsearch.randomizedtesting.rules.StaticFieldsInvariantRule$1.afterAlways(StaticFieldsInvariantRule.java:119)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:43)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at java.lang.Thread.run(Thread.java:662)
Build Log:
[...truncated 7172 lines...]
[junit4:junit4] Suite: org.apache.solr.util.TestNumberUtils
[junit4:junit4] 2 NOTE: test params are: codec=Lucene40: {},
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=hr,
timezone=Asia/Dacca
[junit4:junit4] 2 NOTE: Windows 7 6.1 amd64/Sun Microsystems Inc. 1.6.0_35
(64-bit)/cpus=2,threads=1,free=44755656,total=109666304
[junit4:junit4] 2 NOTE: All tests run in this JVM: [TestConfig,
TestDocumentBuilder, TestDistributedSearch, NoCacheHeaderTest,
HighlighterTest, StandardRequestHandlerTest, TestReload,
DirectSolrConnectionTest, TestWordDelimiterFilterFactory, TestBinaryField,
TestStressRecovery, IndexSchemaTest, UpdateRequestProcessorFactoryTest,
TestWriterPerf, TestSearchPerf, SolrCoreTest, SuggesterTSTTest,
TestQuerySenderNoQuery, MinimalSchemaTest, DateMathParserTest,
SolrCmdDistributorTest, ShowFileRequestHandlerTest, TestFiltering,
SuggesterWFSTTest, TestRandomFaceting, BasicDistributedZkTest,
TestPropInject, TestReversedWildcardFilterFactory, TestGroupingSearch,
RequestHandlersTest, UUIDFieldTest, UpdateParamsTest, ZkSolrClientTest,
QueryEqualityTest, DocumentAnalysisRequestHandlerTest, TimeZoneUtilsTest,
DefaultValueUpdateProcessorTest, RAMDirectoryFactoryTest,
TestFoldingMultitermQuery, SampleTest, TestCodecSupport, TestLFUCache,
TestLMDirichletSimilarityFactory, TestIndexSearcher, DirectUpdateHandlerTest,
ZkControllerTest, TestMultiCoreConfBootstrap, IndexReaderFactoryTest,
TestMergePolicyConfig, TestUtils, ReturnFieldsTest, SpellCheckCollatorTest,
TestSurroundQueryParser, TestQueryTypes, ResourceLoaderTest,
TestPHPSerializedResponseWriter, ScriptEngineTest, PrimitiveFieldTypeTest,
TestExtendedDismaxParser, NumericFieldsTest, PolyFieldTest,
DistributedTermsComponentTest, BasicFunctionalityTest,
AlternateDirectoryTest, AutoCommitTest, SoftAutoCommitTest,
FieldMutatingUpdateProcessorTest, BadIndexSchemaTest,
OpenExchangeRatesOrgProviderTest, PingRequestHandlerTest,
DocumentBuilderTest, TestLRUCache, SearchHandlerTest, ConvertedLegacyTest,
TestUpdate, TestFastOutputStream, TestStressLucene, TestJmxMonitoredMap,
PluginInfoTest, URLClassifyProcessorTest, TestSystemIdResolver,
TestRealTimeGet, XsltUpdateRequestHandlerTest, TestBinaryResponseWriter,
TestSolrDeletionPolicy1, BinaryUpdateRequestHandlerTest, TestDocSet,
TermsComponentTest, TestCollationField, CopyFieldTest, SolrRequestParserTest,
BadComponentTest, TestLuceneMatchVersion,
[jira] [Updated] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError
[
https://issues.apache.org/jira/browse/SOLR-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated SOLR-3849:
Attachment: SOLR-3849.patch
Simple patch to enable headless mode (this makes sense for tests as we dont
need window toolkit).
Does this solve the issue? I have no MacOSX with Cocoa...
See http://docs.oracle.com/javase/1.4.2/docs/guide/awt/AWTChanges.html#headless
for more infor about headless
ScriptEngineTest failure RE system properties and ThreadLeakError
-
Key: SOLR-3849
URL: https://issues.apache.org/jira/browse/SOLR-3849
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 5.0
Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Dawid Weiss
Attachments: SOLR-3849.patch
100% reproducible for me:
solr$ ant test -Dtestcase=ScriptEngineTest
{noformat}
[junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4]
[junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
[junit4:junit4] OK 0.17s | ScriptEngineTest.testPut
[junit4:junit4] OK 0.02s | ScriptEngineTest.testEvalReader
[junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
[junit4:junit4] Assumption #1: got: [null], expected: each not null
[junit4:junit4] OK 0.01s | ScriptEngineTest.testEvalText
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByExtension
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByName
[junit4:junit4] 2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING
Will linger awaiting termination of 2 leaked thread(s).
[junit4:junit4] 2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1
thread leaked from SUITE scope at
org.apache.solr.update.processor.ScriptEngineTest:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll
Starting to interrupt leaked threads:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE
There are still zombie threads that couldn't be terminated:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 NOTE: test params are: codec=SimpleText,
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR,
timezone=America/Edmonton
[junit4:junit4] 2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
[junit4:junit4] 2 NOTE: All tests run in this JVM: [ScriptEngineTest]
[junit4:junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true
-Dtests.locale=es_PR -Dtests.timezone=America/Edmonton
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 0.00s | ScriptEngineTest (suite)
[junit4:junit4] Throwable #1: java.lang.AssertionError: System
properties invariant violated.
[junit4:junit4] New keys:
[junit4:junit4] sun.awt.enableExtraMouseButtons=true
[junit4:junit4] sun.font.fontmanager=sun.font.CFontManager
[junit4:junit4]
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4] at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
[jira] [Commented] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError
[
https://issues.apache.org/jira/browse/SOLR-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457676#comment-13457676
]
Dawid Weiss commented on SOLR-3849:
---
David can you see if Uwe's patch solves the problem? I agree this is probably
AWT starting up for some reason. We can ignore those properties (and threads)
but it's probably better that we caught them -- they shouldn't be running or
starting up.
ScriptEngineTest failure RE system properties and ThreadLeakError
-
Key: SOLR-3849
URL: https://issues.apache.org/jira/browse/SOLR-3849
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 5.0
Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Dawid Weiss
Attachments: SOLR-3849.patch
100% reproducible for me:
solr$ ant test -Dtestcase=ScriptEngineTest
{noformat}
[junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4]
[junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
[junit4:junit4] OK 0.17s | ScriptEngineTest.testPut
[junit4:junit4] OK 0.02s | ScriptEngineTest.testEvalReader
[junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
[junit4:junit4] Assumption #1: got: [null], expected: each not null
[junit4:junit4] OK 0.01s | ScriptEngineTest.testEvalText
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByExtension
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByName
[junit4:junit4] 2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING
Will linger awaiting termination of 2 leaked thread(s).
[junit4:junit4] 2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1
thread leaked from SUITE scope at
org.apache.solr.update.processor.ScriptEngineTest:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll
Starting to interrupt leaked threads:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE
There are still zombie threads that couldn't be terminated:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 NOTE: test params are: codec=SimpleText,
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR,
timezone=America/Edmonton
[junit4:junit4] 2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
[junit4:junit4] 2 NOTE: All tests run in this JVM: [ScriptEngineTest]
[junit4:junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true
-Dtests.locale=es_PR -Dtests.timezone=America/Edmonton
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 0.00s | ScriptEngineTest (suite)
[junit4:junit4] Throwable #1: java.lang.AssertionError: System
properties invariant violated.
[junit4:junit4] New keys:
[junit4:junit4] sun.awt.enableExtraMouseButtons=true
[junit4:junit4] sun.font.fontmanager=sun.font.CFontManager
[junit4:junit4]
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4] at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
[jira] [Commented] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError
[
https://issues.apache.org/jira/browse/SOLR-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457680#comment-13457680
]
Uwe Schindler commented on SOLR-3849:
-
Setting this proerty is a real-world use-case: -Djava.awt.headless=true is e.g.
set by the startup scripts of Tomcat or Jetty, as servlet containers are
software to be run on a server and nothing ever should start up AWT there.
ScriptEngineTest failure RE system properties and ThreadLeakError
-
Key: SOLR-3849
URL: https://issues.apache.org/jira/browse/SOLR-3849
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 5.0
Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Dawid Weiss
Attachments: SOLR-3849.patch
100% reproducible for me:
solr$ ant test -Dtestcase=ScriptEngineTest
{noformat}
[junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4]
[junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
[junit4:junit4] OK 0.17s | ScriptEngineTest.testPut
[junit4:junit4] OK 0.02s | ScriptEngineTest.testEvalReader
[junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
[junit4:junit4] Assumption #1: got: [null], expected: each not null
[junit4:junit4] OK 0.01s | ScriptEngineTest.testEvalText
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByExtension
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByName
[junit4:junit4] 2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING
Will linger awaiting termination of 2 leaked thread(s).
[junit4:junit4] 2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1
thread leaked from SUITE scope at
org.apache.solr.update.processor.ScriptEngineTest:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll
Starting to interrupt leaked threads:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE
There are still zombie threads that couldn't be terminated:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 NOTE: test params are: codec=SimpleText,
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR,
timezone=America/Edmonton
[junit4:junit4] 2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
[junit4:junit4] 2 NOTE: All tests run in this JVM: [ScriptEngineTest]
[junit4:junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true
-Dtests.locale=es_PR -Dtests.timezone=America/Edmonton
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 0.00s | ScriptEngineTest (suite)
[junit4:junit4] Throwable #1: java.lang.AssertionError: System
properties invariant violated.
[junit4:junit4] New keys:
[junit4:junit4] sun.awt.enableExtraMouseButtons=true
[junit4:junit4] sun.font.fontmanager=sun.font.CFontManager
[junit4:junit4]
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4] at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
ant precommit can't find python
I tried running ant precommit on my machine and get this after it cranks away for a while: /Users/Erick/apache/4x/build.xml:59: The following error occurred while executing this line: /Users/Erick/apache/4x/lucene/build.xml:230: The following error occurred while executing this line: /Users/Erick/apache/4x/lucene/common-build.xml:1802: Execute failed: java.io.IOException: Cannot run program python3.2 (in directory /Users/Erick/apache/4x/lucene): error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) at java.lang.Runtime.exec(Runtime.java:593) . . . It appears that I have python 2.6 hanging around on my machine, but I've never used it, so haven't set up anything, and it's the wrong version anyway. Can we add a check for python existing up-front and maybe print a helpful message (I'm thinking something like ivy-bootstrap)? I'm guessing that actually having the executable in 4x/lucene isn't the best solution and I should have an env variable somewhere? Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: ant precommit can't find python
yes you need python3, unfortunately the scripts dont work with python2. I'm not sure what help we could give besides the message already given... for the mac i installed the binary package from http://python.org/download/ On Tue, Sep 18, 2012 at 7:30 AM, Erick Erickson erickerick...@gmail.com wrote: I tried running ant precommit on my machine and get this after it cranks away for a while: /Users/Erick/apache/4x/build.xml:59: The following error occurred while executing this line: /Users/Erick/apache/4x/lucene/build.xml:230: The following error occurred while executing this line: /Users/Erick/apache/4x/lucene/common-build.xml:1802: Execute failed: java.io.IOException: Cannot run program python3.2 (in directory /Users/Erick/apache/4x/lucene): error=2, No such file or directory at java.lang.ProcessBuilder.start(ProcessBuilder.java:460) at java.lang.Runtime.exec(Runtime.java:593) . . . It appears that I have python 2.6 hanging around on my machine, but I've never used it, so haven't set up anything, and it's the wrong version anyway. Can we add a check for python existing up-front and maybe print a helpful message (I'm thinking something like ivy-bootstrap)? I'm guessing that actually having the executable in 4x/lucene isn't the best solution and I should have an env variable somewhere? Erick - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3846) TestReplicationHandler.test always (?) takes many minutes on OS X (lion)
[
https://issues.apache.org/jira/browse/SOLR-3846?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-3846.
--
Resolution: Fixed
trunk: r1387099
4.x : r1387098
Uwe:
Want to open another JIRA for your brainstorm?
TestReplicationHandler.test always (?) takes many minutes on OS X (lion)
Key: SOLR-3846
URL: https://issues.apache.org/jira/browse/SOLR-3846
Project: Solr
Issue Type: Improvement
Components: Build
Affects Versions: 4.0-BETA, 5.0
Environment: OS X (Lion). Apparently (see Yonik's notes) this does
NOT happen on other op systems.
java version 1.6.0_35
Java(TM) SE Runtime Environment (build 1.6.0_35-b10-428-11M3811)
Java HotSpot(TM) 64-Bit Server VM (build 20.10-b01-428, mixed mode)
Solr trunk and 4.x from 16-Sep, but it's been happening for a couple of weeks
at least.
Reporter: Erick Erickson
Assignee: Erick Erickson
Fix For: 4.0, 5.0
Attachments: SOLR-3846.patch, SOLR-3846.patch, SOLR-3846.patch,
SOLR-3846.patch, SOLR-3846.patch, stacks.txt
Here's the seed was using, but this is apparently unnecessary:
JUnit4 says ¡Hola! Master seed: 6785BB3284A15298
_eventually_ it seems to complete, but it takes many minutes, for instance
this was reported once, but I usually lose patience and ctrl-c out:
{code}
[junit4:junit4] Completed on J2 in 2449.62s, 1 test
[junit4:junit4]
[junit4:junit4] JVM J0: 1.21 .. 266.67 = 265.47s
[junit4:junit4] JVM J1: 1.21 .. 238.33 = 237.12s
[junit4:junit4] JVM J2: 1.21 .. 2538.60 = 2537.39s
[junit4:junit4] JVM J3: 0.97 .. 267.37 = 266.40s
[junit4:junit4] Execution time total: 42 minutes 18 seconds
{code}
and a lot of lines like:
HEARTBEAT J2: 2012-09-16T17:38:38, no events in: 187s, approx. at:
TestReplicationHandler.test
Yonik reports that he can make this happen 100% of the time on OS X/Lion,
which squares with my experience as I recall. Yonik also reports...
On my linux box (built in '09, PhenomII, HDD) the test takes 50-55 sec.
On my kids old windows box ('08, athlon64, HDD, Win7) the test takes 88-95
sec.
On my mac it always takes forever, and I see loops of stuff like this:
{code}
SEVERE Master at: http://localhost:62803/solr is not available. Index
fetch failed. Exception:
org.apache.solr.client.solrj.SolrServerException: Server refused
connection at: http://localhost:62803/solr
[junit4:junit4] 2 52751 T219 C17 UPDATE [collection1] webapp=/solr
path=/update params={wt=javabinversion=2} {add=[150]} 0 0
[junit4:junit4] 2 52755 T219 C17 UPDATE [collection1] webapp=/solr
path=/update params={wt=javabinversion=2} {add=[151]} 0 0
[junit4:junit4] 2 62758 T215 oash.SnapPuller.fetchLatestIndex
SEVERE Master at: http://localhost:62803/solr is not available. Index
fetch failed. Exception:
{code}
And I'm s happy it's not happening to others and just being swept under
the rug, restores my faith. I should have known better ;)
See the discussion on the dev list labeled being a good citizen is hard when
you can't successfully run tests for more context.
I don't know how much time I'll have to dive in to it but I'll certainly be
happy to test anyone's patch.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError
[
https://issues.apache.org/jira/browse/SOLR-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457761#comment-13457761
]
Robert Muir commented on SOLR-3849:
---
There used to be at least some solr contrib test that would fire up AWT on my
mac.
I think we should set headless too.
ScriptEngineTest failure RE system properties and ThreadLeakError
-
Key: SOLR-3849
URL: https://issues.apache.org/jira/browse/SOLR-3849
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 5.0
Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Dawid Weiss
Attachments: SOLR-3849.patch
100% reproducible for me:
solr$ ant test -Dtestcase=ScriptEngineTest
{noformat}
[junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4]
[junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
[junit4:junit4] OK 0.17s | ScriptEngineTest.testPut
[junit4:junit4] OK 0.02s | ScriptEngineTest.testEvalReader
[junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
[junit4:junit4] Assumption #1: got: [null], expected: each not null
[junit4:junit4] OK 0.01s | ScriptEngineTest.testEvalText
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByExtension
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByName
[junit4:junit4] 2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING
Will linger awaiting termination of 2 leaked thread(s).
[junit4:junit4] 2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1
thread leaked from SUITE scope at
org.apache.solr.update.processor.ScriptEngineTest:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll
Starting to interrupt leaked threads:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE
There are still zombie threads that couldn't be terminated:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 NOTE: test params are: codec=SimpleText,
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR,
timezone=America/Edmonton
[junit4:junit4] 2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
[junit4:junit4] 2 NOTE: All tests run in this JVM: [ScriptEngineTest]
[junit4:junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true
-Dtests.locale=es_PR -Dtests.timezone=America/Edmonton
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 0.00s | ScriptEngineTest (suite)
[junit4:junit4] Throwable #1: java.lang.AssertionError: System
properties invariant violated.
[junit4:junit4] New keys:
[junit4:junit4] sun.awt.enableExtraMouseButtons=true
[junit4:junit4] sun.font.fontmanager=sun.font.CFontManager
[junit4:junit4]
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4] at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4] at java.lang.Thread.run(Thread.java:722)
[junit4:junit4] Throwable #2:
[jira] [Commented] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError
[
https://issues.apache.org/jira/browse/SOLR-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457765#comment-13457765
]
Uwe Schindler commented on SOLR-3849:
-
+1, we should do this in all cases (unrelated to this issue)
ScriptEngineTest failure RE system properties and ThreadLeakError
-
Key: SOLR-3849
URL: https://issues.apache.org/jira/browse/SOLR-3849
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 5.0
Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Dawid Weiss
Attachments: SOLR-3849.patch
100% reproducible for me:
solr$ ant test -Dtestcase=ScriptEngineTest
{noformat}
[junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4]
[junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
[junit4:junit4] OK 0.17s | ScriptEngineTest.testPut
[junit4:junit4] OK 0.02s | ScriptEngineTest.testEvalReader
[junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
[junit4:junit4] Assumption #1: got: [null], expected: each not null
[junit4:junit4] OK 0.01s | ScriptEngineTest.testEvalText
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByExtension
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByName
[junit4:junit4] 2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING
Will linger awaiting termination of 2 leaked thread(s).
[junit4:junit4] 2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1
thread leaked from SUITE scope at
org.apache.solr.update.processor.ScriptEngineTest:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll
Starting to interrupt leaked threads:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE
There are still zombie threads that couldn't be terminated:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 NOTE: test params are: codec=SimpleText,
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR,
timezone=America/Edmonton
[junit4:junit4] 2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
[junit4:junit4] 2 NOTE: All tests run in this JVM: [ScriptEngineTest]
[junit4:junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true
-Dtests.locale=es_PR -Dtests.timezone=America/Edmonton
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 0.00s | ScriptEngineTest (suite)
[junit4:junit4] Throwable #1: java.lang.AssertionError: System
properties invariant violated.
[junit4:junit4] New keys:
[junit4:junit4] sun.awt.enableExtraMouseButtons=true
[junit4:junit4] sun.font.fontmanager=sun.font.CFontManager
[junit4:junit4]
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4] at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4] at java.lang.Thread.run(Thread.java:722)
[junit4:junit4] Throwable #2:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread
[jira] [Commented] (LUCENE-4404) Add ListOfOutputs FST Outputs, replacing UpToTwoPositiveIntOutputs
[ https://issues.apache.org/jira/browse/LUCENE-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457773#comment-13457773 ] Michael McCandless commented on LUCENE-4404: That's a good point about the bit-stealing: I forgot it did that. So I agree the new ListOfOutputs will likely make a larger FST ... but it shouldn't be so bad since it's only on the node-final outputs that it adds a byte. Also it's more general (can wrap any output (not just PositiveInt), can hold an arbitrary number). So I'll revive UpToTwoPositiveIntOutputs, and move it to misc (nobody actually uses it today... I think BlockTree had used it at one point), and put this new ListOfOutputs into misc too. Add ListOfOutputs FST Outputs, replacing UpToTwoPositiveIntOutputs -- Key: LUCENE-4404 URL: https://issues.apache.org/jira/browse/LUCENE-4404 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: LUCENE-4404.patch Spinoff from LUCENE-3842. This just generalizes the UpToTwoPositiveIntOutputs to a list of any arbitrary output, by wrapping any other Outputs impl. I also made separate methods to write/read a node-final output: since list of values can only occur on a final node output, this impl optimizes and avoids writing an extra byte per label for normal arc labels. This also fixes a bug in Builder that was sometimes failing to join multiple outputs together. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3842) Analyzing Suggester
[ https://issues.apache.org/jira/browse/LUCENE-3842?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-3842: --- Attachment: LUCENE-3842.patch New patch, going back to deduping on the input side... it's not done yet: I think we need to escape the bytes we steal. Analyzing Suggester --- Key: LUCENE-3842 URL: https://issues.apache.org/jira/browse/LUCENE-3842 Project: Lucene - Core Issue Type: New Feature Components: modules/spellchecker Affects Versions: 3.6, 4.0-ALPHA Reporter: Robert Muir Attachments: LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842.patch, LUCENE-3842-TokenStream_to_Automaton.patch Since we added shortest-path wFSA search in LUCENE-3714, and generified the comparator in LUCENE-3801, I think we should look at implementing suggesters that have more capabilities than just basic prefix matching. In particular I think the most flexible approach is to integrate with Analyzer at both build and query time, such that we build a wFST with: input: analyzed text such as ghost0christmas0past -- byte 0 here is an optional token separator output: surface form such as the ghost of christmas past weight: the weight of the suggestion we make an FST with PairOutputsweight,output, but only do the shortest path operation on the weight side (like the test in LUCENE-3801), at the same time accumulating the output (surface form), which will be the actual suggestion. This allows a lot of flexibility: * Using even standardanalyzer means you can offer suggestions that ignore stopwords, e.g. if you type in ghost of chr..., it will suggest the ghost of christmas past * we can add support for synonyms/wdf/etc at both index and query time (there are tradeoffs here, and this is not implemented!) * this is a basis for more complicated suggesters such as Japanese suggesters, where the analyzed form is in fact the reading, so we would add a TokenFilter that copies ReadingAttribute into term text to support that... * other general things like offering suggestions that are more fuzzy like using a plural stemmer or ignoring accents or whatever. According to my benchmarks, suggestions are still very fast with the prototype (e.g. ~ 100,000 QPS), and the FST size does not explode (its short of twice that of a regular wFST, but this is still far smaller than TST or JaSpell, etc). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3766) A test group and build plan for known unstable tests
[
https://issues.apache.org/jira/browse/SOLR-3766?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457833#comment-13457833
]
Yonik Seeley commented on SOLR-3766:
bq. There is a non-intersecting set of strongly defended positions and I don't
see a solution for this.
This is why I originally suggested a different mailing list for those that did
want to see the failures of sporadically failing tests.
Other alternatives:
- run solr tests separately to enable those that don't want to see solr fails
to filter them with their email client
- run Unstable tests separately to enable those that don't want to see solr
fails to filter them with their email client
A test group and build plan for known unstable tests
Key: SOLR-3766
URL: https://issues.apache.org/jira/browse/SOLR-3766
Project: Solr
Issue Type: Task
Reporter: Dawid Weiss
Priority: Minor
As discussed on the mailing list and suggested by Hoss:
{code}
1) slap a special @UnstableTest annotation on them
2) set up a new jenkins job that *only* runs these @UnstableTest jobs
3) configure this new jenkins job to not send any email
{code}
Point 1 is trivial, 2 I have filed an issue for in the runner --
https://github.com/carrotsearch/randomizedtesting/issues/122
that I will take care of shortly.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3843) Add lucene-codecs to Solr libs?
[ https://issues.apache.org/jira/browse/SOLR-3843?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand resolved SOLR-3843. Resolution: Won't Fix Thanks Uwe and Robert for these precisions. I added some documentation on Solr wiki: * http://wiki.apache.org/solr/SchemaXml#Data_Types * http://wiki.apache.org/solr/SolrConfigXml#codecFactory Add lucene-codecs to Solr libs? --- Key: SOLR-3843 URL: https://issues.apache.org/jira/browse/SOLR-3843 Project: Solr Issue Type: Wish Reporter: Adrien Grand Priority: Minor Solr gives the ability to its users to select the postings format to use on a per-field basis but only Lucene40PostingsFormat is available by default (unless users add lucene-codecs to the Solr lib directory). Maybe we should add lucene-codecs to Solr libs (I mean in the WAR file) so that people can try our non-default postings formats with minimum effort? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3815) add hash range to shard
[ https://issues.apache.org/jira/browse/SOLR-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457863#comment-13457863 ] Yonik Seeley commented on SOLR-3815: Looks like Overseer.setShardLeader also modifies previously created (immutable) state. I'll fix. add hash range to shard --- Key: SOLR-3815 URL: https://issues.apache.org/jira/browse/SOLR-3815 Project: Solr Issue Type: Sub-task Reporter: Yonik Seeley Attachments: SOLR-3815_addrange.patch, SOLR-3815_clusterState_immutable.patch, SOLR-3815.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4404) Add ListOfOutputs FST Outputs, replacing UpToTwoPositiveIntOutputs
[ https://issues.apache.org/jira/browse/LUCENE-4404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457867#comment-13457867 ] Robert Muir commented on LUCENE-4404: - I agree, lets put both in misc/. The new one is good because its much more flexible. Add ListOfOutputs FST Outputs, replacing UpToTwoPositiveIntOutputs -- Key: LUCENE-4404 URL: https://issues.apache.org/jira/browse/LUCENE-4404 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: LUCENE-4404.patch Spinoff from LUCENE-3842. This just generalizes the UpToTwoPositiveIntOutputs to a list of any arbitrary output, by wrapping any other Outputs impl. I also made separate methods to write/read a node-final output: since list of values can only occur on a final node output, this impl optimizes and avoids writing an extra byte per label for normal arc labels. This also fixes a bug in Builder that was sometimes failing to join multiple outputs together. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError
[
https://issues.apache.org/jira/browse/SOLR-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457869#comment-13457869
]
David Smiley commented on SOLR-3849:
Patch worked!
ScriptEngineTest failure RE system properties and ThreadLeakError
-
Key: SOLR-3849
URL: https://issues.apache.org/jira/browse/SOLR-3849
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 5.0
Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Dawid Weiss
Attachments: SOLR-3849.patch
100% reproducible for me:
solr$ ant test -Dtestcase=ScriptEngineTest
{noformat}
[junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4]
[junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
[junit4:junit4] OK 0.17s | ScriptEngineTest.testPut
[junit4:junit4] OK 0.02s | ScriptEngineTest.testEvalReader
[junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
[junit4:junit4] Assumption #1: got: [null], expected: each not null
[junit4:junit4] OK 0.01s | ScriptEngineTest.testEvalText
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByExtension
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByName
[junit4:junit4] 2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING
Will linger awaiting termination of 2 leaked thread(s).
[junit4:junit4] 2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1
thread leaked from SUITE scope at
org.apache.solr.update.processor.ScriptEngineTest:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll
Starting to interrupt leaked threads:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE
There are still zombie threads that couldn't be terminated:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 NOTE: test params are: codec=SimpleText,
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR,
timezone=America/Edmonton
[junit4:junit4] 2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
[junit4:junit4] 2 NOTE: All tests run in this JVM: [ScriptEngineTest]
[junit4:junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true
-Dtests.locale=es_PR -Dtests.timezone=America/Edmonton
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 0.00s | ScriptEngineTest (suite)
[junit4:junit4] Throwable #1: java.lang.AssertionError: System
properties invariant violated.
[junit4:junit4] New keys:
[junit4:junit4] sun.awt.enableExtraMouseButtons=true
[junit4:junit4] sun.font.fontmanager=sun.font.CFontManager
[junit4:junit4]
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4] at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4] at java.lang.Thread.run(Thread.java:722)
[junit4:junit4] Throwable #2:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from
SUITE scope at
[jira] [Commented] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError
[
https://issues.apache.org/jira/browse/SOLR-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457877#comment-13457877
]
Uwe Schindler commented on SOLR-3849:
-
OK, I commit that one!
ScriptEngineTest failure RE system properties and ThreadLeakError
-
Key: SOLR-3849
URL: https://issues.apache.org/jira/browse/SOLR-3849
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 5.0
Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Dawid Weiss
Attachments: SOLR-3849.patch
100% reproducible for me:
solr$ ant test -Dtestcase=ScriptEngineTest
{noformat}
[junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4]
[junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
[junit4:junit4] OK 0.17s | ScriptEngineTest.testPut
[junit4:junit4] OK 0.02s | ScriptEngineTest.testEvalReader
[junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
[junit4:junit4] Assumption #1: got: [null], expected: each not null
[junit4:junit4] OK 0.01s | ScriptEngineTest.testEvalText
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByExtension
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByName
[junit4:junit4] 2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING
Will linger awaiting termination of 2 leaked thread(s).
[junit4:junit4] 2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1
thread leaked from SUITE scope at
org.apache.solr.update.processor.ScriptEngineTest:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll
Starting to interrupt leaked threads:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE
There are still zombie threads that couldn't be terminated:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 NOTE: test params are: codec=SimpleText,
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR,
timezone=America/Edmonton
[junit4:junit4] 2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
[junit4:junit4] 2 NOTE: All tests run in this JVM: [ScriptEngineTest]
[junit4:junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true
-Dtests.locale=es_PR -Dtests.timezone=America/Edmonton
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 0.00s | ScriptEngineTest (suite)
[junit4:junit4] Throwable #1: java.lang.AssertionError: System
properties invariant violated.
[junit4:junit4] New keys:
[junit4:junit4] sun.awt.enableExtraMouseButtons=true
[junit4:junit4] sun.font.fontmanager=sun.font.CFontManager
[junit4:junit4]
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4] at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4] at java.lang.Thread.run(Thread.java:722)
[junit4:junit4] Throwable #2:
com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked from
SUITE scope at
[jira] [Resolved] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError
[
https://issues.apache.org/jira/browse/SOLR-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler resolved SOLR-3849.
-
Resolution: Fixed
Fix Version/s: 5.0
4.0
Assignee: Uwe Schindler (was: Dawid Weiss)
Committed trunk revision: 1387212
Committed 4.x revision: 1387213
Thanks for trying out!
ScriptEngineTest failure RE system properties and ThreadLeakError
-
Key: SOLR-3849
URL: https://issues.apache.org/jira/browse/SOLR-3849
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 5.0
Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Uwe Schindler
Fix For: 4.0, 5.0
Attachments: SOLR-3849.patch
100% reproducible for me:
solr$ ant test -Dtestcase=ScriptEngineTest
{noformat}
[junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4]
[junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
[junit4:junit4] OK 0.17s | ScriptEngineTest.testPut
[junit4:junit4] OK 0.02s | ScriptEngineTest.testEvalReader
[junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
[junit4:junit4] Assumption #1: got: [null], expected: each not null
[junit4:junit4] OK 0.01s | ScriptEngineTest.testEvalText
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByExtension
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByName
[junit4:junit4] 2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING
Will linger awaiting termination of 2 leaked thread(s).
[junit4:junit4] 2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1
thread leaked from SUITE scope at
org.apache.solr.update.processor.ScriptEngineTest:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll
Starting to interrupt leaked threads:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE
There are still zombie threads that couldn't be terminated:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 NOTE: test params are: codec=SimpleText,
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR,
timezone=America/Edmonton
[junit4:junit4] 2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
[junit4:junit4] 2 NOTE: All tests run in this JVM: [ScriptEngineTest]
[junit4:junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true
-Dtests.locale=es_PR -Dtests.timezone=America/Edmonton
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 0.00s | ScriptEngineTest (suite)
[junit4:junit4] Throwable #1: java.lang.AssertionError: System
properties invariant violated.
[junit4:junit4] New keys:
[junit4:junit4] sun.awt.enableExtraMouseButtons=true
[junit4:junit4] sun.font.fontmanager=sun.font.CFontManager
[junit4:junit4]
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4] at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4] at
Is this a SolrCloud bug? Or expected behavior?
I've got a set up as follows: - 13 cores - 2 servers - running Solr 4.0 Beta with numShards=1 and an external zookeeper. I'm trying to figure out why some complex queries are running so slowly in this setup versus quickly in a standalone mode. Given a query like: /select?q=(some complex query) It runs fast and gets faster (caches) when only running one server: 1. ?fl=*q=(complex query)wt=jsonrows=24 (QTime 3) When, I issue the same query to the cluster and watch the logs, it looks like it's actually performing the query 3 times like so: 1. ?q=(complex query)distrib=falsewt=javabinrows=24version=2NOW=1347911018556shard.url=(server1)|(server2)fl=id,scoredf=textstart=0isShard=truefsv=true (QTime 2) 2. ?ids=(ids from query 1)distrib=falsewt=javabinrows=24version=2df=textfl=*shard.url=(server1)|(server2)NOW=1347911018556start=0q=(complex query)isShard=true (QTime 4) 3. ?fl=*q=(complex query)wt=jsonrows=24 (QTime 459) Why is it performing #3? It already has everything it needs in #2 and #3 seems to be really slow even when warmed and cached. As stated above, this query is fast when running on a single server that is warmed and cached. Since my query is complex, I could understand some slowness if I was attempting this across multiple shards, but since there's only one shard, shouldn't it just pick one server and query it? I can fix this by adding distrib=false to my original queries, but then that sort of makes the whole cluster meaningless. Ideally, I'd just spin up a new server that attaches itself to zookeeper and add it to my load balancer and forget about it. Thanks! Jim -- View this message in context: http://lucene.472066.n3.nabble.com/Is-this-a-SolrCloud-bug-Or-expected-behavior-tp4008629.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2411) clean up uses of String.toLowerCase in code
[
https://issues.apache.org/jira/browse/LUCENE-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457898#comment-13457898
]
Steven Rowe commented on LUCENE-2411:
-
I think this can be closed as fixed, given that {{-check-forbidden-jdk-apis}}
prohibits {{String.toLowerCase()}}: LUCENE-4199.
clean up uses of String.toLowerCase in code
---
Key: LUCENE-2411
URL: https://issues.apache.org/jira/browse/LUCENE-2411
Project: Lucene - Core
Issue Type: Bug
Components: modules/analysis
Affects Versions: 3.1
Reporter: Robert Muir
Fix For: 4.1
Uwe recently fixed this in the ThaiWordFilter, which reminded me to search
our code for use of String.toLowerCase()
The problem with this method is the following:
* it depends on the default locale which is flimsy and should be avoided I
think, it typically just causes problems.
This is because there can be hard-to-debug issues if the machine is not
configured correctly for the same Locale
at both index and query time.
* lowercasing with locale-sensitive rules is really only suitable for display
and presentation,
if we want international lowercasing for search we should be using case
folding.
This is especially important since otherwise people unknowingly using this
special casing at query-time are
not going to get results, e.g. if they use a TermRangeQuery from the
queryparser and it lowercases stuff differently.
in my opinion we should fix all these methods to use Character.toLowerCase
(if possible especially for speed with TokenStreams), otherwise
String.toLowerCase
with the ROOT Locale, new Locale(). This is closer to case folding.
If some things really need locale-sensitivity for some extreme reason I think
we should just make the Locale
a mandatory parameter.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3402) LuceneTestCase shouldn't go crazy if a test fails in an @AfterClass annotated method
[ https://issues.apache.org/jira/browse/LUCENE-3402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-3402. - Resolution: Fixed LuceneTestCase shouldn't go crazy if a test fails in an @AfterClass annotated method Key: LUCENE-3402 URL: https://issues.apache.org/jira/browse/LUCENE-3402 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-3402.patch, LUCENE-3402.patch An example can be seen here: http://sierranevada.servebeer.com/1314308641.log The general problem is this: the assertions and cleanups in lucenetestcase's afterclass should be reordered, and have better error handling. In this particular case these were the steps that happened: # AutoCommitTest didn't close its searchers, so SolrTestCaseJ4 threw an assertion exception in its @AfterClass method. # Because the searcher wasn't closed, LuceneTestCase threw an assertion exception about unclosed directories/file handles in its afterClass. Even though the test had already failed it ran this assertion because testsFailed is false, since our TestWatchMan isnt aware of failures that happen in @AfterClass methods :( # Because it threw this exception, it never made it to the part where it resets the random, so the next test blew up in its BeforeClass. To add insult to injury, all this happened but we didnt get a random seed printed, so we cant even hope to reproduce the situation. After discussion with hossman, we came up with some ideas on how to improve this, and I'm adding some i just thought of, too: # try to divide up these assertions and cleanups in LuceneTestCase: we could use multiple @AfterClass-annotated methods but then i'm not sure we can control the order, which is scary. But one safe thing to do is to put these pieces of code in little methods and afterclass can handle this stuff with try/finally. # think about exposing the testsFailed variable for subclasses that do assertions in their @AfterClasses. otherwise you might not get a random seed, which is bad. # think about upgrading junit, because I know from experimentation that the TestWatchMan (or whatever its replacement is) can see more of the test lifecycle and this would probably make a lot of this much cleaner. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3259) need to clarify/change DPenum api for hasPayload/getPayload
[ https://issues.apache.org/jira/browse/LUCENE-3259?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-3259. - Resolution: Fixed Fix Version/s: 4.0 need to clarify/change DPenum api for hasPayload/getPayload Key: LUCENE-3259 URL: https://issues.apache.org/jira/browse/LUCENE-3259 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Fix For: 4.0 We encountered this bug while integrating the faceting module: * DPEnum says getPayload() will return null if there is no payload. * however, in some cases this is not what happens. * things do work (with no exceptions), if you always check hasPayload() first. The easiest fix could be to correct the javadocs, and say that you should always check hasPayload() first... otherwise getPayload() is not defined. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-2411) clean up uses of String.toLowerCase in code
[ https://issues.apache.org/jira/browse/LUCENE-2411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-2411. - Resolution: Fixed Fix Version/s: (was: 4.1) 4.0 clean up uses of String.toLowerCase in code --- Key: LUCENE-2411 URL: https://issues.apache.org/jira/browse/LUCENE-2411 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Affects Versions: 3.1 Reporter: Robert Muir Fix For: 4.0 Uwe recently fixed this in the ThaiWordFilter, which reminded me to search our code for use of String.toLowerCase() The problem with this method is the following: * it depends on the default locale which is flimsy and should be avoided I think, it typically just causes problems. This is because there can be hard-to-debug issues if the machine is not configured correctly for the same Locale at both index and query time. * lowercasing with locale-sensitive rules is really only suitable for display and presentation, if we want international lowercasing for search we should be using case folding. This is especially important since otherwise people unknowingly using this special casing at query-time are not going to get results, e.g. if they use a TermRangeQuery from the queryparser and it lowercases stuff differently. in my opinion we should fix all these methods to use Character.toLowerCase (if possible especially for speed with TokenStreams), otherwise String.toLowerCase with the ROOT Locale, new Locale(). This is closer to case folding. If some things really need locale-sensitivity for some extreme reason I think we should just make the Locale a mandatory parameter. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3732) overview.html needs help
[ https://issues.apache.org/jira/browse/LUCENE-3732?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-3732. - Resolution: Fixed Fix Version/s: 4.0 overview.html needs help Key: LUCENE-3732 URL: https://issues.apache.org/jira/browse/LUCENE-3732 Project: Lucene - Core Issue Type: Bug Affects Versions: 3.6, 4.0-ALPHA Reporter: Robert Muir Assignee: Robert Muir Fix For: 4.0 Attachments: LUCENE-3732.patch, LUCENE-3732.patch When you open javadocs, this is the very first thing you see (index.html). It has a bunch of sample code and links that are broken. In some situations I can see it was updated here and there, but others (like javadocs links) link to java 1.2 javadocs no longer online, etc. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3735) Relocate the example mime-to-extension mapping
[ https://issues.apache.org/jira/browse/SOLR-3735?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457903#comment-13457903 ] Robert Muir commented on SOLR-3735: --- What's the status on this issue... no updates in a while, is it going to make 4.0? Relocate the example mime-to-extension mapping -- Key: SOLR-3735 URL: https://issues.apache.org/jira/browse/SOLR-3735 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA Reporter: Erik Hatcher Assignee: Erik Hatcher Priority: Minor Fix For: 4.0 Attachments: SOLR-3735.patch A mime-to-extension mapping was added to VelocityResponseWriter recently. This really belongs in the templates themselves, not in VrW, as it is specific to the example search results not meant for all VrW templates. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-4391) Lucene40Codec methods should be final
[
https://issues.apache.org/jira/browse/LUCENE-4391?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand resolved LUCENE-4391.
--
Resolution: Fixed
Just committed (r1387222 on trunk and r1387229 on branch 4.x).
Lucene40Codec methods should be final
-
Key: LUCENE-4391
URL: https://issues.apache.org/jira/browse/LUCENE-4391
Project: Lucene - Core
Issue Type: Bug
Reporter: Adrien Grand
Assignee: Adrien Grand
Fix For: 4.0
Attachments: LUCENE-4391.patch, LUCENE-4391.patch
I think all methods but {{getPostingsFormatForField}} should be made final so
that users can't create a Codec that redefines any of the formats of Lucene40
by subclassing (since the codec name can't be overriden by subclassing,
Lucene will fail at loading segments that use such codecs).
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3425) CloudSolrServer can't create cores when using the zkHost based constructor
[ https://issues.apache.org/jira/browse/SOLR-3425?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457905#comment-13457905 ] Robert Muir commented on SOLR-3425: --- Mark/Tommaso, can you guys look at this issue? I notice it hasn't been touched in months. is it going to make 4.0? CloudSolrServer can't create cores when using the zkHost based constructor -- Key: SOLR-3425 URL: https://issues.apache.org/jira/browse/SOLR-3425 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Tommaso Teofili Assignee: Mark Miller Priority: Minor Fix For: 4.0, 5.0 Attachments: SOLR-3425-test.patch When programmatically creating cores with a running SolrCloud instance the CloudSolrServer uses the slices nodes information to feed the underlying LBHttpSolrServer so it fails to create cores as there aren't any slices for any new collection (as it's still to be created). This happens when using the CloudSolrServer constructor which takes the ZK host as only parameter while it can be avoided by using the constructor which also takes the list of Solr URLs and the underlying LBHttpSolrServer is actually used for making the core creation request. However it'd be good to use the ZK host live nodes information to automatically issue a core creation command on one of the underlying Solr hosts without having to specify the full list of URLs beforehand. The scenario is when one wants to create a collection with N shards so the client sends N core creation requests for the same collection thus the SolrCloud stuff should just take care of choosing the host where to issue the core creation request and update the cluster state. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3230) Performance improvement for geofilt by doing a bbox approximation and then Filter
[
https://issues.apache.org/jira/browse/SOLR-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457906#comment-13457906
]
Robert Muir commented on SOLR-3230:
---
What's the status on this issue: it hasn't been touched for months. Is it going
to make 4.0?
Performance improvement for geofilt by doing a bbox approximation and then
Filter
-
Key: SOLR-3230
URL: https://issues.apache.org/jira/browse/SOLR-3230
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Yonik Seeley
Fix For: 4.0
Attachments: SOLR-3230-3.patch, SOLR-3230.patch
This changes {!geofilt} to use a bounding box and then does a accurate filter.
See attachment
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3777) dataimporthandler interface does not send 'false' for unchecked checkboxes. Index is 'clean'ed every time
[ https://issues.apache.org/jira/browse/SOLR-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457907#comment-13457907 ] Robert Muir commented on SOLR-3777: --- I'm not a javascript expert: can someone review the patch here? dataimporthandler interface does not send 'false' for unchecked checkboxes. Index is 'clean'ed every time -- Key: SOLR-3777 URL: https://issues.apache.org/jira/browse/SOLR-3777 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler, web gui Affects Versions: 4.0-BETA Reporter: Glenn MacStravic Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.0 Attachments: SOLR-3777.patch The checkboxes for 'verbose', 'clean', 'optimize', 'commit' are only sent as arguments when checked. Clearing the checkbox has no effect, so unintended operations are conducted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3376) SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent.
[ https://issues.apache.org/jira/browse/SOLR-3376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457908#comment-13457908 ] Robert Muir commented on SOLR-3376: --- Is this still a problem now that zookeeper has been upgraded? SolrCloud: Specifying shardId not working correctly, although the failures are inconsistent. Key: SOLR-3376 URL: https://issues.apache.org/jira/browse/SOLR-3376 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Erick Erickson Assignee: Sami Siren Fix For: 4.0 I'm seeing some odd results when specifying shardId parameter. I'm trying the 4-node, 2-shard example from the Wiki and specifying shardIds like this: dir shardId start orderrunnng ZK port example 1 1 y8983 example22 2 y7574 example31 3 y8900 example42 4 y7500 And I'm waiting a bit between starting various examples to let ZK settle down. Once all of them are started, I was looking at http://localhost:8983/solr/#/~cloud?view=graph to check out what that looks like (pretty cool IMO, especially since I didn't have to do it). The problem was that shard 2 only reported a single instance, while shard1 showed the two instances I was expecting. I'm running with 3 embedded ZK instances, just for yucks. Interestingly the node that didn't show up was the only node that was NOT running ZK. When I removed all the shardId parameters, nuked zoo_data from all directories and just started them up (with numShards=2 on the bootstrap ZK node), all 4 nodes showed up just fine. When starting with shardId specified and trying to go straight to the admin interface on the node that wasn't showing up, I'd get odd errors like This interface requires that you activate the admin request handlers, add the following configuration to your solrconfig.xml:. I also couldn't search directly on that machine, http://localhost:7574/solr/select?q=*:*; returns a 404 error. Command starting server that's giving me trouble: java -Xmx1G -Djetty.port=7500 -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=2 -jar start.jar Command for one that works fine: java -Xmx1G -Djetty.port=8900 -DzkRun -DzkHost=localhost:9983,localhost:8574,localhost:9900 -DshardId=1 -jar start.jar Sami Siren and he reports similar issues via e-mail conversation. Sami says that ZK 3.3.5 apparently (without exhaustive tests) fixed the problem for him, but when I tried ZK 3.3.5 I saw the same issue. Of course with all the recent stuff with Ivy, I may have screwed up when/where the JARs were. So then I went back to ZK 3.3.4 and couldn't reproduce the problem. Which seems highly suspicious to me. It was failing every time before with 3.3.4, so it sounds like gremlins. And then I tried ZK 3.3.5 again (changed the ivy.xml in solrj, blew away the ZK 3.3.4, rebuilt, removed zoo_data, recopied example to three other directories) and it works fine there too now. Sh. Mostly this is a placeholder to insure we try this, I guarantee that sys admins will want to assign specific machines to specific shards, so this'll get used. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3777) dataimporthandler interface does not send 'false' for unchecked checkboxes. Index is 'clean'ed every time
[ https://issues.apache.org/jira/browse/SOLR-3777?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457909#comment-13457909 ] Stefan Matheis (steffkes) commented on SOLR-3777: - Yepp, i'll do so today dataimporthandler interface does not send 'false' for unchecked checkboxes. Index is 'clean'ed every time -- Key: SOLR-3777 URL: https://issues.apache.org/jira/browse/SOLR-3777 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler, web gui Affects Versions: 4.0-BETA Reporter: Glenn MacStravic Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.0 Attachments: SOLR-3777.patch The checkboxes for 'verbose', 'clean', 'optimize', 'commit' are only sent as arguments when checked. Clearing the checkbox has no effect, so unintended operations are conducted. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3613) Namespace Solr's JAVA OPTIONS
[
https://issues.apache.org/jira/browse/SOLR-3613?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457912#comment-13457912
]
Robert Muir commented on SOLR-3613:
---
Whats going on here, is this going to make 4.0?
Namespace Solr's JAVA OPTIONS
-
Key: SOLR-3613
URL: https://issues.apache.org/jira/browse/SOLR-3613
Project: Solr
Issue Type: Improvement
Affects Versions: 4.0-ALPHA
Reporter: Jan Høydahl
Assignee: Jan Høydahl
Fix For: 4.0
Solr being a web-app, should play nicely in a setting where users deploy it
on a shared appServer.
To this regard Solr's JAVA_OPTS should be properly name spaced, both to avoid
name clashes and for clarity when reading your appserver startup script. We
currently do that with most: {{solr.solr.home, solr.data.dir,
solr.abortOnConfigurationError, solr.directoryFactory,
solr.clustering.enabled, solr.velocity.enabled etc}}, but for some opts we
fail to do so.
Before release of 4.0 we should make sure to clean this up.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3685) Solr Cloud sometimes skipped peersync attempt and replicated instead due to tlog flags not being cleared when no updates were buffered during a previous replication.
[ https://issues.apache.org/jira/browse/SOLR-3685?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457914#comment-13457914 ] Robert Muir commented on SOLR-3685: --- Whats happening with this issue: is it still one? should it be critical/block 4.0? Solr Cloud sometimes skipped peersync attempt and replicated instead due to tlog flags not being cleared when no updates were buffered during a previous replication. - Key: SOLR-3685 URL: https://issues.apache.org/jira/browse/SOLR-3685 Project: Solr Issue Type: Bug Components: replication (java), SolrCloud Affects Versions: 4.0-ALPHA Environment: Debian GNU/Linux Squeeze 64bit Solr 5.0-SNAPSHOT 1365667M - markus - 2012-07-25 19:09:43 Reporter: Markus Jelsma Assignee: Yonik Seeley Priority: Critical Fix For: 4.0, 5.0 Attachments: info.log, oom-killer.log, pmap.log There's a serious problem with restarting nodes, not cleaning old or unused index directories and sudden replication and Java being killed by the OS due to excessive memory allocation. Since SOLR-1781 was fixed index directories get cleaned up when a node is being restarted cleanly, however, old or unused index directories still pile up if Solr crashes or is being killed by the OS, happening here. We have a six-node 64-bit Linux test cluster with each node having two shards. There's 512MB RAM available and no swap. Each index is roughly 27MB so about 50MB per node, this fits easily and works fine. However, if a node is being restarted, Solr will consistently crash because it immediately eats up all RAM. If swap is enabled Solr will eat an additional few 100MB's right after start up. This cannot be solved by restarting Solr, it will just crash again and leave index directories in place until the disk is full. The only way i can restart a node safely is to delete the index directories and have it replicate from another node. If i then restart the node it will crash almost consistently. I'll attach a log of one of the nodes. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Is this a SolrCloud bug? Or expected behavior?
On Tue, Sep 18, 2012 at 11:49 AM, jimtronic jimtro...@gmail.com wrote: I've got a set up as follows: - 13 cores - 2 servers - running Solr 4.0 Beta with numShards=1 and an external zookeeper. I'm trying to figure out why some complex queries are running so slowly in this setup versus quickly in a standalone mode. Given a query like: /select?q=(some complex query) It runs fast and gets faster (caches) when only running one server: 1. ?fl=*q=(complex query)wt=jsonrows=24 (QTime 3) When, I issue the same query to the cluster and watch the logs, it looks like it's actually performing the query 3 times like so: 1. ?q=(complex query)distrib=falsewt=javabinrows=24version=2NOW=1347911018556shard.url=(server1)|(server2)fl=id,scoredf=textstart=0isShard=truefsv=true (QTime 2) 2. ?ids=(ids from query 1)distrib=falsewt=javabinrows=24version=2df=textfl=*shard.url=(server1)|(server2)NOW=1347911018556start=0q=(complex query)isShard=true (QTime 4) 3. ?fl=*q=(complex query)wt=jsonrows=24 (QTime 459) #1 and #2 are sub-requests (different phases of the top level request). #3 is the log for the top level original request that made #1 and #2 and encompasses the time for both of them. Why is it performing #3? It already has everything it needs in #2 and #3 seems to be really slow even when warmed and cached. As stated above, this query is fast when running on a single server that is warmed and cached. Since my query is complex, I could understand some slowness if I was attempting this across multiple shards, but since there's only one shard, shouldn't it just pick one server and query it? A distributed search that happens to only hit a single shard is something we haven't optimized for yet. -Yonik http://lucidworks.com I can fix this by adding distrib=false to my original queries, but then that sort of makes the whole cluster meaningless. Ideally, I'd just spin up a new server that attaches itself to zookeeper and add it to my load balancer and forget about it. Thanks! Jim - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-860) site should call project Lucene Java, not just Lucene
[ https://issues.apache.org/jira/browse/LUCENE-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe resolved LUCENE-860. Resolution: Fixed Fix Version/s: (was: 4.1) AFAICT, this was committed long ago. These site pages were changed from Lucene Java to Lucene Core by [~gsingers] for the Lucene 3.1 release in March 2010. site should call project Lucene Java, not just Lucene - Key: LUCENE-860 URL: https://issues.apache.org/jira/browse/LUCENE-860 Project: Lucene - Core Issue Type: Improvement Components: general/website Reporter: Doug Cutting Assignee: Mark Miller Priority: Minor Attachments: LUCENE-860-1.patch, LUCENE-860-2.patch, LUCENE-860.patch To avoid confusion with the top-level Lucene project, the Lucene Java website should refer to itself as Lucene Java. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4406) Print out where tests failed at the end of running the Test Suite
Grant Ingersoll created LUCENE-4406:
---
Summary: Print out where tests failed at the end of running the
Test Suite
Key: LUCENE-4406
URL: https://issues.apache.org/jira/browse/LUCENE-4406
Project: Lucene - Core
Issue Type: Bug
Components: general/test
Reporter: Grant Ingersoll
Priority: Minor
It would be nice if, at the end of running ant test, it spit out the names of
which tests failed so that one doesn't have to go scrolling up through the
output or go run grep on the test-reports as a separate step.
For another project, I use:
{code}
target name=test-summary
echoLooking for summaries in: ${build.dir}/test-reports with basedir:
${basedir}/echo
echoErrors:/echo
exec executable=grep
arg value=-r/
arg value=-rl/
arg value=errors=\quot;[1-9]\quot;/
arg value=${build.dir}/test-reports/
/exec
echoFailures:/echo
exec executable=grep
arg value=-r/
arg value=-rl/
arg value=failures=\quot;[1-9]\quot;/
arg value=${build.dir}/test-reports/
/exec
/target
{code}
which can likely be modified for Lucene. I can do it, but wanted to see if
others had an opinion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Is this a SolrCloud bug? Or expected behavior?
Start by adding debugQuery=true to your query request and look at the timings for the various search components. You know, there has been some recent chatter about slowness of references to localhost vs. 127.0.0.1. Who knows, maybe that could be a factor here. -- Jack Krupansky -Original Message- From: jimtronic Sent: Tuesday, September 18, 2012 11:49 AM To: dev@lucene.apache.org Subject: Is this a SolrCloud bug? Or expected behavior? I've got a set up as follows: - 13 cores - 2 servers - running Solr 4.0 Beta with numShards=1 and an external zookeeper. I'm trying to figure out why some complex queries are running so slowly in this setup versus quickly in a standalone mode. Given a query like: /select?q=(some complex query) It runs fast and gets faster (caches) when only running one server: 1. ?fl=*q=(complex query)wt=jsonrows=24 (QTime 3) When, I issue the same query to the cluster and watch the logs, it looks like it's actually performing the query 3 times like so: 1. ?q=(complex query)distrib=falsewt=javabinrows=24version=2NOW=1347911018556shard.url=(server1)|(server2)fl=id,scoredf=textstart=0isShard=truefsv=true (QTime 2) 2. ?ids=(ids from query 1)distrib=falsewt=javabinrows=24version=2df=textfl=*shard.url=(server1)|(server2)NOW=1347911018556start=0q=(complex query)isShard=true (QTime 4) 3. ?fl=*q=(complex query)wt=jsonrows=24 (QTime 459) Why is it performing #3? It already has everything it needs in #2 and #3 seems to be really slow even when warmed and cached. As stated above, this query is fast when running on a single server that is warmed and cached. Since my query is complex, I could understand some slowness if I was attempting this across multiple shards, but since there's only one shard, shouldn't it just pick one server and query it? I can fix this by adding distrib=false to my original queries, but then that sort of makes the whole cluster meaningless. Ideally, I'd just spin up a new server that attaches itself to zookeeper and add it to my load balancer and forget about it. Thanks! Jim -- View this message in context: http://lucene.472066.n3.nabble.com/Is-this-a-SolrCloud-bug-Or-expected-behavior-tp4008629.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4406) Print out where tests failed at the end of running the Test Suite
[
https://issues.apache.org/jira/browse/LUCENE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457924#comment-13457924
]
Steven Rowe commented on LUCENE-4406:
-
+1
Print out where tests failed at the end of running the Test Suite
-
Key: LUCENE-4406
URL: https://issues.apache.org/jira/browse/LUCENE-4406
Project: Lucene - Core
Issue Type: Bug
Components: general/test
Reporter: Grant Ingersoll
Priority: Minor
It would be nice if, at the end of running ant test, it spit out the names of
which tests failed so that one doesn't have to go scrolling up through the
output or go run grep on the test-reports as a separate step.
For another project, I use:
{code}
target name=test-summary
echoLooking for summaries in: ${build.dir}/test-reports with basedir:
${basedir}/echo
echoErrors:/echo
exec executable=grep
arg value=-r/
arg value=-rl/
arg value=errors=\quot;[1-9]\quot;/
arg value=${build.dir}/test-reports/
/exec
echoFailures:/echo
exec executable=grep
arg value=-r/
arg value=-rl/
arg value=failures=\quot;[1-9]\quot;/
arg value=${build.dir}/test-reports/
/exec
/target
{code}
which can likely be modified for Lucene. I can do it, but wanted to see if
others had an opinion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3815) add hash range to shard
[ https://issues.apache.org/jira/browse/SOLR-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457928#comment-13457928 ] Robert Muir commented on SOLR-3815: --- I think you intended to backport r1386858 to 4.x? add hash range to shard --- Key: SOLR-3815 URL: https://issues.apache.org/jira/browse/SOLR-3815 Project: Solr Issue Type: Sub-task Reporter: Yonik Seeley Attachments: SOLR-3815_addrange.patch, SOLR-3815_clusterState_immutable.patch, SOLR-3815.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-772) Index corruption can cause infinite spin loop when Lucene attempts to incorrectly uncompress fields
[ https://issues.apache.org/jira/browse/LUCENE-772?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe updated LUCENE-772: --- Fix Version/s: (was: 4.1) 3.6.2 Changed fix version to 3.6.2, which, if released, will be the final Lucene version that supports reading compressed fields in indexes created by Lucene 2.X. See LUCENE-1960. Index corruption can cause infinite spin loop when Lucene attempts to incorrectly uncompress fields --- Key: LUCENE-772 URL: https://issues.apache.org/jira/browse/LUCENE-772 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 2.1 Environment: Linux (gentoo 2.6.17 at least), jdk 1.5.0_06 and _08 at least, tomcat 5.5. IndexSearcher searching index mounted via NFS; using new lockless commits... We're using the 01-05-07 nightly build of lucene Reporter: Arthur Smith Fix For: 3.6.2 Unfortunately I don't have a reproducible case of this (yet), but it's happened twice now on our production servers in the past few days, after we switched to the new lockless commits (thanks!). What we're seeing is the search thread running away in the middle of a seemingly ordinary search, after several hundred thousand queries that worked just fine. The search index is NFS mounted, and is updated every minute or so during the day by an indexing process running on a separate server. We do get occasional I/O errors, but we catch and retry and it seems ok after a few seconds. But twice now we've had run-away threads; the thread dump in both cases was caught in the middle of java.util.zip.Inflater: http-8080-3 daemon prio=1 tid=0x08294688 nid=0x1f0d runnable [0x1f17c000..0x1f17e0b0] at java.util.zip.Inflater.inflateBytes(Native Method) at java.util.zip.Inflater.inflate(Inflater.java:215) - locked 0x3d73cba8 (a java.util.zip.Inflater) at java.util.zip.Inflater.inflate(Inflater.java:232) at org.apache.lucene.index.FieldsReader.uncompress(FieldsReader.java:388) at org.apache.lucene.index.FieldsReader.addField(FieldsReader.java:222) at org.apache.lucene.index.FieldsReader.doc(FieldsReader.java:105) at org.apache.lucene.index.SegmentReader.document(SegmentReader.java:324) - locked 0x3cefbdd8 (a org.apache.lucene.index.SegmentReader) at org.apache.lucene.index.MultiReader.document(MultiReader.java:108) at org.apache.lucene.index.IndexReader.document(IndexReader.java:360) at org.apache.lucene.search.IndexSearcher.doc(IndexSearcher.java:84) at org.apache.lucene.search.Hits.doc(Hits.java:104) [...] Any ideas what this could be? Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4175) Include BBox Spatial Strategy
[ https://issues.apache.org/jira/browse/LUCENE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457938#comment-13457938 ] Robert Muir commented on LUCENE-4175: - Is it still by intention that this is not backported to 4.x? I just want to be sure. Include BBox Spatial Strategy - Key: LUCENE-4175 URL: https://issues.apache.org/jira/browse/LUCENE-4175 Project: Lucene - Core Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: LUCENE-4175-bbox-strategy.patch This is an approach to indexing bounding boxes using 4 numeric fields (xmin,ymin,xmax,ymax) and a flag to say if it crosses the dateline. This is a modification from the Apache 2.0 code from the ESRI Geoportal: http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-858) link from Lucene web page to API docs
[ https://issues.apache.org/jira/browse/LUCENE-858?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe resolved LUCENE-858. Resolution: Fixed Fix Version/s: (was: 4.1) There are now links from the versioned demo pages to nicely formatted source code. link from Lucene web page to API docs - Key: LUCENE-858 URL: https://issues.apache.org/jira/browse/LUCENE-858 Project: Lucene - Core Issue Type: Improvement Components: general/website Reporter: Daniel Naber There should be a way to link from e.g. http://lucene.apache.org/java/docs/gettingstarted.html to the API docs, but not just to the start page with the frame set but to a specific page, e.g. this: http://lucene.zones.apache.org:8080/hudson/job/Lucene-Nightly/javadoc/overview-summary.html#overview_description To make this work a way to set a relative link is needed. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3815) add hash range to shard
[ https://issues.apache.org/jira/browse/SOLR-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457942#comment-13457942 ] Yonik Seeley commented on SOLR-3815: bq. I think you intended to backport r1386858 to 4.x? Yep - I hadn't noticed my commit failed. Committed in r1387245 add hash range to shard --- Key: SOLR-3815 URL: https://issues.apache.org/jira/browse/SOLR-3815 Project: Solr Issue Type: Sub-task Reporter: Yonik Seeley Attachments: SOLR-3815_addrange.patch, SOLR-3815_clusterState_immutable.patch, SOLR-3815.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3564) rename IndexWriter.rollback to .rollbackAndClose
[ https://issues.apache.org/jira/browse/LUCENE-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457950#comment-13457950 ] Steven Rowe commented on LUCENE-3564: - bq. I guess it's OK to leave rollback as short but misleading; it's a fairly expert API. Also, it quickly becomes obvious to the user that the IW was closed, so it's fail fast and the damage is not nearly as bad as what we see when users don't understand the cost of optimize. Mike, should this issue be resolved as won't fix? rename IndexWriter.rollback to .rollbackAndClose Key: LUCENE-3564 URL: https://issues.apache.org/jira/browse/LUCENE-3564 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.1 Spinoff from LUCENE-3454, where Shai noticed that rollback is trappy since it [unexpected] closes the IW. I think we should rename it to rollbackAndClose. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-3564) rename IndexWriter.rollback to .rollbackAndClose
[
https://issues.apache.org/jira/browse/LUCENE-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457950#comment-13457950
]
Steven Rowe edited comment on LUCENE-3564 at 9/19/12 3:56 AM:
--
{quote}
I guess it's OK to leave rollback as short but misleading; it's a
fairly expert API. Also, it quickly becomes obvious to the user that
the IW was closed, so it's fail fast and the damage is not nearly as
bad as what we see when users don't understand the cost of optimize.
{quote}
Mike, should this issue be resolved as won't fix?
was (Author: steve_rowe):
bq. I guess it's OK to leave rollback as short but misleading; it's a
fairly expert API. Also, it quickly becomes obvious to the user that
the IW was closed, so it's fail fast and the damage is not nearly as
bad as what we see when users don't understand the cost of optimize.
Mike, should this issue be resolved as won't fix?
rename IndexWriter.rollback to .rollbackAndClose
Key: LUCENE-3564
URL: https://issues.apache.org/jira/browse/LUCENE-3564
Project: Lucene - Core
Issue Type: Improvement
Reporter: Michael McCandless
Assignee: Michael McCandless
Fix For: 4.1
Spinoff from LUCENE-3454, where Shai noticed that rollback is trappy since it
[unexpected] closes the IW.
I think we should rename it to rollbackAndClose.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (LUCENE-860) site should call project Lucene Java, not just Lucene
[ https://issues.apache.org/jira/browse/LUCENE-860?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Grant Ingersoll closed LUCENE-860. -- Steve, correct. Closing this. site should call project Lucene Java, not just Lucene - Key: LUCENE-860 URL: https://issues.apache.org/jira/browse/LUCENE-860 Project: Lucene - Core Issue Type: Improvement Components: general/website Reporter: Doug Cutting Assignee: Mark Miller Priority: Minor Attachments: LUCENE-860-1.patch, LUCENE-860-2.patch, LUCENE-860.patch To avoid confusion with the top-level Lucene project, the Lucene Java website should refer to itself as Lucene Java. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3230) Performance improvement for geofilt by doing a bbox approximation and then Filter
[
https://issues.apache.org/jira/browse/SOLR-3230?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13457967#comment-13457967
]
David Smiley commented on SOLR-3230:
FYI, FWIW the new SpatialTwoDoubles does a bbox range query approximation and
then does the distance calculation for a circle query shape after. I'm
referring to the Solr adapter to a corresponding Lucene 4 spatial strategy
class. Looking through the comments above, it seems another option I didn't
consider was doing the bbox range on the fieldcache (so-called frange style).
Performance improvement for geofilt by doing a bbox approximation and then
Filter
-
Key: SOLR-3230
URL: https://issues.apache.org/jira/browse/SOLR-3230
Project: Solr
Issue Type: Improvement
Reporter: Bill Bell
Assignee: Yonik Seeley
Fix For: 4.0
Attachments: SOLR-3230-3.patch, SOLR-3230.patch
This changes {!geofilt} to use a bounding box and then does a accurate filter.
See attachment
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3850) DIH: parameter cacheKey was inadvertently renamed cachePk
James Dyer created SOLR-3850: Summary: DIH: parameter cacheKey was inadvertently renamed cachePk Key: SOLR-3850 URL: https://issues.apache.org/jira/browse/SOLR-3850 Project: Solr Issue Type: Bug Affects Versions: 4.0-BETA, 3.6.1 Reporter: James Dyer Assignee: James Dyer Fix For: 4.0, 3.6.2 CachedSqlEntityProcessor supports an obscure alternate to the where parameter. Instead of entity ... where='id=x.id' / , users can use entity ... cacheKey=id cacheLookup=x.id / However, this was broken with SOLR-2382. cacheKey was accidently renamed cachePk. For the sake of those who might be using this undocumented syntax and want to upgrade, I think it should be put back to cacheKey. Also, I will add documentation in the wiki. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-2725) Bengali Analyzer for Lucene has been Developed
[ https://issues.apache.org/jira/browse/LUCENE-2725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe resolved LUCENE-2725. - Resolution: Incomplete Fix Version/s: (was: 4.1) Lucene Fields: (was: New) Ahmed, if/when you're ready to contribute, please reopen this issue. Bengali Analyzer for Lucene has been Developed -- Key: LUCENE-2725 URL: https://issues.apache.org/jira/browse/LUCENE-2725 Project: Lucene - Core Issue Type: New Feature Components: modules/analysis Affects Versions: 3.0.1 Environment: Environment Independent Reporter: Ahmed Chisty Hi everyone, I am a CSE student of SUST, SYlhet( http://www.sust.edu/). I have noticed that there is no such Bengali Analyzer in Lucene for Bengali Text search and highlight. I have used Standard Analyzer and others but they do not give good result. So, i have developed a Bengali Analyzer. I have tested it for 50 thousand document. And it is being used in Ekushe Finance Search Engine. (http://efinance.com.bd/). Please give me some instruction so that i can contribute that analyzer in Lucene. Thanx. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-2644) LowerCaseTokenizer Does Not Behave As One Might Expect (or Desire)--Given Its Name
[ https://issues.apache.org/jira/browse/LUCENE-2644?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe resolved LUCENE-2644. - Resolution: Won't Fix Fix Version/s: (was: 4.1) Scott, I agree with [~rcmuir] - LowerCaseTokenizer has been around since at least 2001 (when Lucene came to the ASF) with well-defined behavior. I think the way forward here is to make a new issue that creates a new tokenizer performing the things you want to see, with a new name. Resolving as Won't Fix. LowerCaseTokenizer Does Not Behave As One Might Expect (or Desire)--Given Its Name -- Key: LUCENE-2644 URL: https://issues.apache.org/jira/browse/LUCENE-2644 Project: Lucene - Core Issue Type: Wish Components: modules/analysis Affects Versions: 3.0.2 Reporter: Scott Gonyea Attachments: LowerCaseTokenizer.patch While I understand some of the reasons for its design, the original LowerCaseTokenizer should have been named LowerCaseLetterTokenizer. I feel that LowerCaseTokenizer makes too many assumptions about what too tokenize, and I have therefore patched it. The *default* behavior will remain as it always has--to avoid breaking any implementations for which it's being used. I have changed LowerCaseTokenizer to extend CharTokenizer (rather than LetterTokenizer). LetterTokenizer's functionality was merged into the default behavior of LowerCaseTokenizer. Getter/Setter methods have been added to the LowerCaseTokenizer Class, allowing you to turn on / off tokenizing by white space, numbers, and special (Non-Alpha/Numeric) characters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3564) rename IndexWriter.rollback to .rollbackAndClose
[ https://issues.apache.org/jira/browse/LUCENE-3564?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless resolved LUCENE-3564. Resolution: Won't Fix Yeah I think so. Naming is the hardest part :) rename IndexWriter.rollback to .rollbackAndClose Key: LUCENE-3564 URL: https://issues.apache.org/jira/browse/LUCENE-3564 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.1 Spinoff from LUCENE-3454, where Shai noticed that rollback is trappy since it [unexpected] closes the IW. I think we should rename it to rollbackAndClose. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-2544) Add 'divisor' to NumericField, allows for easy storage of full precision data, but indexing *starting* at lower precision.
[ https://issues.apache.org/jira/browse/LUCENE-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe resolved LUCENE-2544. - Resolution: Won't Fix Fix Version/s: (was: 4.1) Lucene Fields: (was: New) Given the fact that this just provides sugar over existing functionality, and considering [~thetaphi]'s objections, and the two years with zero activity, resolving as Won't Fix. Add 'divisor' to NumericField, allows for easy storage of full precision data, but indexing *starting* at lower precision. -- Key: LUCENE-2544 URL: https://issues.apache.org/jira/browse/LUCENE-2544 Project: Lucene - Core Issue Type: Improvement Components: core/other Affects Versions: 3.0.2 Reporter: Woody Anderson Priority: Minor Attachments: LUCENE-2544.patch In some cases, we want to index a timestamp or some other high precision numeric at a much lower precision, but we still want to store the full precision data. Rather than have to do this with two Field objects in the Document, it'd be easier to provide NumericField with a divisor as well as prevision step. The divisor would apply before beginning the trie logic. most often, this is a divide by 1, but that will happen only during the constructor or setXXXValue() in NumericTokenStream. I have the patch for this, or i will after i isolate it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4406) Print out where tests failed at the end of running the Test Suite
[
https://issues.apache.org/jira/browse/LUCENE-4406?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458008#comment-13458008
]
Dawid Weiss commented on LUCENE-4406:
-
There are a few different ways to do it. I can also modify the default text
report to include such an information, or we could extract it from ANT test
XMLs generated during the run (this can be misleading if there are existing
XMLs in the output directory and one runs just a subset of tests). I wouldn't
use exec grep because this isn't always available (windows machines). There
is a task for Ant that does it I'm sure (or it can be built).
I think the easiest way would be to include failed tests (or suites?) at the
end via an attribute on the text report in randomized testing. Let me know if
you'd want it done this way.
Print out where tests failed at the end of running the Test Suite
-
Key: LUCENE-4406
URL: https://issues.apache.org/jira/browse/LUCENE-4406
Project: Lucene - Core
Issue Type: Bug
Components: general/test
Reporter: Grant Ingersoll
Priority: Minor
It would be nice if, at the end of running ant test, it spit out the names of
which tests failed so that one doesn't have to go scrolling up through the
output or go run grep on the test-reports as a separate step.
For another project, I use:
{code}
target name=test-summary
echoLooking for summaries in: ${build.dir}/test-reports with basedir:
${basedir}/echo
echoErrors:/echo
exec executable=grep
arg value=-r/
arg value=-rl/
arg value=errors=\quot;[1-9]\quot;/
arg value=${build.dir}/test-reports/
/exec
echoFailures:/echo
exec executable=grep
arg value=-r/
arg value=-rl/
arg value=failures=\quot;[1-9]\quot;/
arg value=${build.dir}/test-reports/
/exec
/target
{code}
which can likely be modified for Lucene. I can do it, but wanted to see if
others had an opinion.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3849) ScriptEngineTest failure RE system properties and ThreadLeakError
[
https://issues.apache.org/jira/browse/SOLR-3849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458010#comment-13458010
]
Dawid Weiss commented on SOLR-3849:
---
Good to see these assertions are actually useful for spotting things like this.
Thanks for testing, guys.
ScriptEngineTest failure RE system properties and ThreadLeakError
-
Key: SOLR-3849
URL: https://issues.apache.org/jira/browse/SOLR-3849
Project: Solr
Issue Type: Bug
Components: update
Affects Versions: 5.0
Environment: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
Reporter: David Smiley
Assignee: Uwe Schindler
Fix For: 4.0, 5.0
Attachments: SOLR-3849.patch
100% reproducible for me:
solr$ ant test -Dtestcase=ScriptEngineTest
{noformat}
[junit4:junit4] JUnit4 says hi! Master seed: E62CC5FBAC2CEFA4
[junit4:junit4] Executing 1 suite with 1 JVM.
[junit4:junit4]
[junit4:junit4] Suite: org.apache.solr.update.processor.ScriptEngineTest
[junit4:junit4] OK 0.17s | ScriptEngineTest.testPut
[junit4:junit4] OK 0.02s | ScriptEngineTest.testEvalReader
[junit4:junit4] IGNOR/A 0.10s | ScriptEngineTest.testJRuby
[junit4:junit4] Assumption #1: got: [null], expected: each not null
[junit4:junit4] OK 0.01s | ScriptEngineTest.testEvalText
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByExtension
[junit4:junit4] OK 0.01s | ScriptEngineTest.testGetEngineByName
[junit4:junit4] 2 -9 T9 ccr.ThreadLeakControl.checkThreadLeaks WARNING
Will linger awaiting termination of 2 leaked thread(s).
[junit4:junit4] 2 20163 T9 ccr.ThreadLeakControl.checkThreadLeaks SEVERE 1
thread leaked from SUITE scope at
org.apache.solr.update.processor.ScriptEngineTest:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 20164 T9 ccr.ThreadLeakControl.tryToInterruptAll
Starting to interrupt leaked threads:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 23172 T9 ccr.ThreadLeakControl.tryToInterruptAll SEVERE
There are still zombie threads that couldn't be terminated:
[junit4:junit4] 2 1) Thread[id=11, name=AppKit Thread, state=RUNNABLE,
group=main]
[junit4:junit4] 2 at (empty stack)
[junit4:junit4] 2 NOTE: test params are: codec=SimpleText,
sim=RandomSimilarityProvider(queryNorm=true,coord=yes): {}, locale=es_PR,
timezone=America/Edmonton
[junit4:junit4] 2 NOTE: Mac OS X 10.8.1 x86_64/Oracle Corporation 1.7.0_07
(64-bit)/cpus=4,threads=1,free=65764312,total=85065728
[junit4:junit4] 2 NOTE: All tests run in this JVM: [ScriptEngineTest]
[junit4:junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=ScriptEngineTest -Dtests.seed=E62CC5FBAC2CEFA4 -Dtests.slow=true
-Dtests.locale=es_PR -Dtests.timezone=America/Edmonton
-Dtests.file.encoding=UTF-8
[junit4:junit4] ERROR 0.00s | ScriptEngineTest (suite)
[junit4:junit4] Throwable #1: java.lang.AssertionError: System
properties invariant violated.
[junit4:junit4] New keys:
[junit4:junit4] sun.awt.enableExtraMouseButtons=true
[junit4:junit4] sun.font.fontmanager=sun.font.CFontManager
[junit4:junit4]
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:66)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
[junit4:junit4] at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
[junit4:junit4] at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
[junit4:junit4] at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
[junit4:junit4] at java.lang.Thread.run(Thread.java:722)
[junit4:junit4]
[jira] [Commented] (SOLR-3823) Parentheses in a boost query cause errors
[
https://issues.apache.org/jira/browse/SOLR-3823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458013#comment-13458013
]
Erik Hatcher commented on SOLR-3823:
bq. I see no evidence that bq is incorrectly using the defType parser in
either dismax or edismax
Ok, sorry I misinterpreted the nature of this issue apparently.
Parentheses in a boost query cause errors
-
Key: SOLR-3823
URL: https://issues.apache.org/jira/browse/SOLR-3823
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 4.0-BETA
Environment: Mac, jdk 1.6, Chrome
Reporter: Mathos Marcer
Assignee: Hoss Man
Fix For: 4.0, 5.0
When using a boost query (bq) that contains a parentheses (like this example
from the Relevancy Cookbook section of the wiki):
{noformat}
? defType = dismax
q = foo bar
bq = (*:* -xxx)^999
{noformat}
You get the following error:
org.apache.lucene.queryparser.classic.ParseException: Cannot parse '-xxx)':
Encountered ) ) at line 1, column 12. Was expecting one of: EOF
AND ... OR ... NOT ... + ... - ... BAREOPER ... ( ... * ...
^ ... QUOTED ... TERM ... FUZZY_SLOP ... PREFIXTERM ... WILDTERM
... REGEXPTERM ... [ ... { ... NUMBER ...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4402) TestAddTaxonomy.testConcurrency failure
[
https://issues.apache.org/jira/browse/LUCENE-4402?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458032#comment-13458032
]
Shai Erera commented on LUCENE-4402:
I'll dig.
TestAddTaxonomy.testConcurrency failure
---
Key: LUCENE-4402
URL: https://issues.apache.org/jira/browse/LUCENE-4402
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Affects Versions: 3.6.2
Reporter: Robert Muir
on the 3.x branch:
{noformat}
[junit] Testsuite:
org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy
[junit] Testcase:
testConcurrency(org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy):
Caused an ERROR
[junit] Index: 1, Size: 2
[junit] java.lang.IndexOutOfBoundsException: Index: 1, Size: 2
[junit] at java.util.ArrayList.rangeCheck(ArrayList.java:604)
[junit] at java.util.ArrayList.get(ArrayList.java:382)
[junit] at
org.apache.lucene.facet.taxonomy.writercache.cl2o.CharBlockArray.charAt(CharBlockArray.java:148)
[junit] at
org.apache.lucene.facet.taxonomy.CategoryPath.equalsToSerialized(CategoryPath.java:888)
[junit] at
org.apache.lucene.facet.taxonomy.writercache.cl2o.CompactLabelToOrdinal.getOrdinal(CompactLabelToOrdinal.java:323)
[junit] at
org.apache.lucene.facet.taxonomy.writercache.cl2o.CompactLabelToOrdinal.getOrdinal(CompactLabelToOrdinal.java:163)
[junit] at
org.apache.lucene.facet.taxonomy.writercache.cl2o.Cl2oTaxonomyWriterCache.get(Cl2oTaxonomyWriterCache.java:49)
[junit] at
org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyWriter.findCategory(DirectoryTaxonomyWriter.java:386)
[junit] at
org.apache.lucene.facet.taxonomy.directory.DirectoryTaxonomyWriter.addTaxonomy(DirectoryTaxonomyWriter.java:833)
[junit] at
org.apache.lucene.facet.taxonomy.directory.TestAddTaxonomy.testConcurrency(TestAddTaxonomy.java:206)
[junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
[junit] at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
[junit] at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
[junit] at java.lang.reflect.Method.invoke(Method.java:601)
[junit] at
org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
[junit] at
org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
[junit] at
org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
[junit] at
org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
[junit] at
org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:630)
[junit] at
org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:536)
[junit] at
org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:67)
[junit] at
org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:457)
[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
[junit] at
org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:508)
[junit] at org.junit.rules.RunRules.evaluate(RunRules.java:18)
[junit] at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
[junit] at
org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:146)
[junit] at
org.apache.lucene.util.LuceneTestCaseRunner.runChild(LuceneTestCaseRunner.java:50)
[junit] at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
[junit] at
org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
[junit] at
org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
[junit] at
org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
[junit] at
org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
[junit] at
org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
[junit] at
org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
[junit] at
org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:74)
[junit] at
[jira] [Updated] (SOLR-3850) DIH: parameter cacheKey was inadvertently renamed cachePk
[ https://issues.apache.org/jira/browse/SOLR-3850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-3850: - Attachment: SOLR-3850.patch I plan to commit this to trunk, 4.x 3.x shortly. DIH: parameter cacheKey was inadvertently renamed cachePk -- Key: SOLR-3850 URL: https://issues.apache.org/jira/browse/SOLR-3850 Project: Solr Issue Type: Bug Affects Versions: 3.6.1, 4.0-BETA Reporter: James Dyer Assignee: James Dyer Fix For: 4.0, 3.6.2 Attachments: SOLR-3850.patch CachedSqlEntityProcessor supports an obscure alternate to the where parameter. Instead of entity ... where='id=x.id' / , users can use entity ... cacheKey=id cacheLookup=x.id / However, this was broken with SOLR-2382. cacheKey was accidently renamed cachePk. For the sake of those who might be using this undocumented syntax and want to upgrade, I think it should be put back to cacheKey. Also, I will add documentation in the wiki. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-2504) sorting performance regression
[ https://issues.apache.org/jira/browse/LUCENE-2504?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe resolved LUCENE-2504. - Resolution: Fixed Fix Version/s: (was: 4.1) 4.0-ALPHA sorting performance regression -- Key: LUCENE-2504 URL: https://issues.apache.org/jira/browse/LUCENE-2504 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.0-ALPHA Reporter: Yonik Seeley Fix For: 4.0-ALPHA Attachments: LUCENE-2504.patch, LUCENE-2504.patch, LUCENE-2504.patch, LUCENE-2504_SortMissingLast.patch, LUCENE-2504.zip sorting can be much slower on trunk than branch_3x -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4175) Include BBox Spatial Strategy
[ https://issues.apache.org/jira/browse/LUCENE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458050#comment-13458050 ] David Smiley commented on LUCENE-4175: -- The BBoxStrategy is tested insofar as search filtering and returning the standard center-point distance as a ValueSource. But it contains a lot of code pertaining to an area overlap similarity as a ValueSource (very cool stuff) but that isn't tested at all, and that's my only concern. If we want to be cautious about avoiding releasing untested code, then I suggest back-porting BBoxStrategy to 4x (pretty easy) but not the AreaSimilarity class. The reference to it in BBoxStrategy is the method makeBBoxAreaSimilarityValueSource() which can be commented out in trunk. Sound good? Include BBox Spatial Strategy - Key: LUCENE-4175 URL: https://issues.apache.org/jira/browse/LUCENE-4175 Project: Lucene - Core Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: LUCENE-4175-bbox-strategy.patch This is an approach to indexing bounding boxes using 4 numeric fields (xmin,ymin,xmax,ymax) and a flag to say if it crosses the dateline. This is a modification from the Apache 2.0 code from the ESRI Geoportal: http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-4175) Include BBox Spatial Strategy
[ https://issues.apache.org/jira/browse/LUCENE-4175?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458050#comment-13458050 ] David Smiley edited comment on LUCENE-4175 at 9/19/12 5:52 AM: --- The BBoxStrategy is tested insofar as search filtering and returning the standard center-point distance as a ValueSource. But it contains a lot of code pertaining to an area overlap similarity as a ValueSource (very cool stuff) but that isn't tested at all, and that's my only concern. If we want to be cautious about avoiding releasing untested code, then I suggest back-porting BBoxStrategy to 4x (pretty easy) but not the AreaSimilarity class. The reference to it in BBoxStrategy is the method makeBBoxAreaSimilarityValueSource() which can be commented out in 4x. Sound good? was (Author: dsmiley): The BBoxStrategy is tested insofar as search filtering and returning the standard center-point distance as a ValueSource. But it contains a lot of code pertaining to an area overlap similarity as a ValueSource (very cool stuff) but that isn't tested at all, and that's my only concern. If we want to be cautious about avoiding releasing untested code, then I suggest back-porting BBoxStrategy to 4x (pretty easy) but not the AreaSimilarity class. The reference to it in BBoxStrategy is the method makeBBoxAreaSimilarityValueSource() which can be commented out in trunk. Sound good? Include BBox Spatial Strategy - Key: LUCENE-4175 URL: https://issues.apache.org/jira/browse/LUCENE-4175 Project: Lucene - Core Issue Type: Improvement Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: LUCENE-4175-bbox-strategy.patch This is an approach to indexing bounding boxes using 4 numeric fields (xmin,ymin,xmax,ymax) and a flag to say if it crosses the dateline. This is a modification from the Apache 2.0 code from the ESRI Geoportal: http://geoportal.svn.sourceforge.net/svnroot/geoportal/Geoportal/trunk/src/com/esri/gpt/catalog/lucene/SpatialClauseAdapter.java -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2403) contrib/HighFreqTerms should use ByteRefs but provide human-readable output
[ https://issues.apache.org/jira/browse/LUCENE-2403?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458062#comment-13458062 ] Steven Rowe commented on LUCENE-2403: - The Lucid link is now dead too :(. Here's a MarkMail.org link: [http://markmail.org/thread/2nl4jhegxbnal4fe] contrib/HighFreqTerms should use ByteRefs but provide human-readable output --- Key: LUCENE-2403 URL: https://issues.apache.org/jira/browse/LUCENE-2403 Project: Lucene - Core Issue Type: Bug Components: modules/other Affects Versions: 3.1 Reporter: Tom Burton-West Priority: Trivial Fix For: 4.1 contrib HighFreqTerms was upgraded to use the flex APIs but currently displays hex code if you do not give a field argument and strings if you do. The conversion to a string should be consistent and should occur just before output rather than when loading the priority queue See: http://n3.nabble.com/Bug-in-contrib-misc-HighFreqTerms-java-tc719202.html#a719202 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4399) Rename AppendingCodec to Appending40Codec
[ https://issues.apache.org/jira/browse/LUCENE-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458063#comment-13458063 ] Michael McCandless commented on LUCENE-4399: +1 to fixing any wrapped PostingsFormats to save the name of what they wrapped into the index. Pulsing currently wraps a PostingsBaseFormat because it needs to intervene on a term by term basis on the communication b/w the terms dict and the postings format it wraps. It would be really nice if we could wrap a PostingsFormat instead of a PostingsBaseFormat instead ... I'm just not sure how. Separately I really don't like the name PostingsBaseFormat :) But I can't think of something better ... it's basically the PostingsFormat minus the terms dict. Rename AppendingCodec to Appending40Codec - Key: LUCENE-4399 URL: https://issues.apache.org/jira/browse/LUCENE-4399 Project: Lucene - Core Issue Type: New Feature Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 4.0 In order AppendingCodec to follow Lucene codecs version, I think its name should include a version number (so that, for example, if we get to releave Lucene 4.3 with a new Lucene43Codec, there will also be a new Appending43Codec). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3825) Log document IDs when they are retrieved
[ https://issues.apache.org/jira/browse/SOLR-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458068#comment-13458068 ] Grant Ingersoll commented on SOLR-3825: --- Thanks, Scott. I committed the updated patch with one minor change. Log document IDs when they are retrieved Key: SOLR-3825 URL: https://issues.apache.org/jira/browse/SOLR-3825 Project: Solr Issue Type: Improvement Components: SearchComponents - other Reporter: Scott Stults Assignee: Grant Ingersoll Priority: Trivial Attachments: SOLR-3825.1.patch, SOLR-3825.patch During relevancy tuning it's important to know exactly which documents the client has seen. Right now the only way to get that list is to splice into the HTTP traffic. Preferably the IDs could be logged along with the query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #617: POMs out of sync
On Tue, Sep 18, 2012 at 3:28 PM, Steven A Rowe sar...@syr.edu wrote: Three out of five of the last trunk Maven builds have failed in SyncSliceTest.testDistribSearch - maybe a timeout needs upward adjustment or something? Unfortunately Mark is traveling this week... But I wonder if the issue is mainly on freebsd? http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/ -Yonik http://lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-2306) contrib/xml-query-parser: NumericRangeQuery and -Filter support
[ https://issues.apache.org/jira/browse/LUCENE-2306?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Rowe resolved LUCENE-2306. - Resolution: Fixed Fix Version/s: (was: 4.1) 3.1 Lucene Fields: (was: New) contrib/xml-query-parser: NumericRangeQuery and -Filter support --- Key: LUCENE-2306 URL: https://issues.apache.org/jira/browse/LUCENE-2306 Project: Lucene - Core Issue Type: Improvement Components: modules/other Affects Versions: 3.0.1 Reporter: Jingkei Ly Assignee: Mark Harwood Fix For: 3.1 Attachments: LUCENE-2306.patch, LUCENE-2306.patch Create a FilterBuilder for NumericRangeFilter so that it may be used with the XML query parser. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Typo in Javadoc for Solr CopyField.getMaxChars: tha - the
/**
* @return tha maximum number of chars in source field to copy to destination
field.
*/
public int getMaxChars() {
tha s.b. the.
See:
http://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/schema/CopyField.java
Typo is in 4.0 as well.
Also, the getLimitedValue method is missing method Javadoc.
-- Jack Krupansky
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3815) add hash range to shard
[ https://issues.apache.org/jira/browse/SOLR-3815?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458151#comment-13458151 ] Yonik Seeley commented on SOLR-3815: Committed Overseer.setShardLeader fix. trunk: http://svn.apache.org/viewvc?rev=1387354view=rev 4x: http://svn.apache.org/viewvc?rev=1387355view=rev add hash range to shard --- Key: SOLR-3815 URL: https://issues.apache.org/jira/browse/SOLR-3815 Project: Solr Issue Type: Sub-task Reporter: Yonik Seeley Attachments: SOLR-3815_addrange.patch, SOLR-3815_clusterState_immutable.patch, SOLR-3815.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
TestIndexWriterWithThreads.testRollbackAndCommitWithThreads looping for 4x on Windows
I am seeing a very long HEARTBEAT list for TestIndexWriterWithThreads.testRollbackAndCommitWithThreads with a recent checkout of branch_4x on Windows. Currently at: no events in: 2288s, approx. at: TestIndexWriterWithThreads.testRollbackAndCommitWithThreads. CPU is relatively idle (25%). Latest trunk checkout was not having this issue for me in my numerous test runs over the past few days. This is my first 4x test in the last two days. -- Jack Krupansky
Re: TestIndexWriterWithThreads.testRollbackAndCommitWithThreads looping for 4x on Windows
You can either wait (if something is hung then after ~2 hours a timeout will occur) or: jps - identify the stalled VM jstack [pid] and post a JIRA issue if you believe something hung. The random seed used for this test will be part of the stack trace but you can attach it too. Dawid On Tue, Sep 18, 2012 at 11:20 PM, Jack Krupansky j...@basetechnology.com wrote: I am seeing a very long HEARTBEAT list for TestIndexWriterWithThreads.testRollbackAndCommitWithThreads with a recent checkout of branch_4x on Windows. Currently at: no events in: 2288s, approx. at: TestIndexWriterWithThreads.testRollbackAndCommitWithThreads. CPU is relatively idle (25%). Latest trunk checkout was not having this issue for me in my numerous test runs over the past few days. This is my first 4x test in the last two days. -- Jack Krupansky - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4399) Rename AppendingCodec to Appending40Codec
[ https://issues.apache.org/jira/browse/LUCENE-4399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458198#comment-13458198 ] Adrien Grand commented on LUCENE-4399: -- bq. It would be really nice if we could wrap a PostingsFormat instead of a PostingsBaseFormat instead ... I'm just not sure how. That would be great. This way we wouldn't need to create a SPI loader for PostingsBaseFormat in order to let Pulsing store/restore the wrapped PostingsBaseFormat. bq. But I can't think of something better ... it's basically the PostingsFormat minus the terms dict. So maybe it is PostingsFormat that should be renamed (PostingsAndTermsFormat?) :-) Rename AppendingCodec to Appending40Codec - Key: LUCENE-4399 URL: https://issues.apache.org/jira/browse/LUCENE-4399 Project: Lucene - Core Issue Type: New Feature Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Fix For: 4.0 In order AppendingCodec to follow Lucene codecs version, I think its name should include a version number (so that, for example, if we get to releave Lucene 4.3 with a new Lucene43Codec, there will also be a new Appending43Codec). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Spatial field names in Solr
This past Sunday I added 3 spatial field types to Solr in SOLR-3304: SpatialTwoDoublesFieldType, SpatialRecursivePrefixTreeFieldType and SpatialTermQueryPrefixTreeFieldType. Eventually there will also be a SpatialBBoxFieldType following this naming convention. These are named in a consistent way based on SpatialStrategy subclasses in the Lucene spatial module. Of course, Solr 3 introduced PointType and LatLonType. What do people think of these Solr field type names? They are kind of long; perhaps the Field parts can be removed. Maybe L4 should precede each of these names? (a Lucene 4 spatial module reference). It would further delineate these fields from the Solr native fields. And about TwoDoubles in particular... I had a tough time coming up with a name for that in the first place as I wanted to avoid a LatLon variation in its name as I think that's a bad idea. For whatever reason I didn't simply choose Point. I opened LUCENE-4374 to rename this SpatialStrategy subclass, suggesting PointVectorStrategy. But maybe PointStrategy is fine. Ideally the name suggests something about its implementation since there very well may be alternative indexing strategies in the future for a given type. ~ David - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4397) TestIndexWriterWithThreads.testRollbackAndCommitWithThreads is sometimes very very slow
[ https://issues.apache.org/jira/browse/LUCENE-4397?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458225#comment-13458225 ] Jack Krupansky commented on LUCENE-4397: My latest test for branch_4x finished this test in 2771.02 seconds on Windows. No errors were reported. CPU was relatively idle whenever I checked (25%). In Eclipse it took 316 seconds (while ant test was still running the rest of the tests.) On trunk, TestIndexWriterWithThreads took 90 seconds. TestIndexWriterWithThreads.testRollbackAndCommitWithThreads is sometimes very very slow --- Key: LUCENE-4397 URL: https://issues.apache.org/jira/browse/LUCENE-4397 Project: Lucene - Core Issue Type: Bug Components: general/test Reporter: Robert Muir e.g. ant test -Dtestcase=TestIndexWriterWithThreads -Dtests.seed=C9BE919B1BE0DAC7 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: TestIndexWriterWithThreads.testRollbackAndCommitWithThreads looping for 4x on Windows
I posted comments for this specific case on LUCENE-4397. It did in fact finish. -- Jack Krupansky -Original Message- From: Dawid Weiss Sent: Tuesday, September 18, 2012 5:26 PM To: dev@lucene.apache.org Subject: Re: TestIndexWriterWithThreads.testRollbackAndCommitWithThreads looping for 4x on Windows You can either wait (if something is hung then after ~2 hours a timeout will occur) or: jps - identify the stalled VM jstack [pid] and post a JIRA issue if you believe something hung. The random seed used for this test will be part of the stack trace but you can attach it too. Dawid On Tue, Sep 18, 2012 at 11:20 PM, Jack Krupansky j...@basetechnology.com wrote: I am seeing a very long HEARTBEAT list for TestIndexWriterWithThreads.testRollbackAndCommitWithThreads with a recent checkout of branch_4x on Windows. Currently at: no events in: 2288s, approx. at: TestIndexWriterWithThreads.testRollbackAndCommitWithThreads. CPU is relatively idle (25%). Latest trunk checkout was not having this issue for me in my numerous test runs over the past few days. This is my first 4x test in the last two days. -- Jack Krupansky - 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-772) Index corruption can cause infinite spin loop when Lucene attempts to incorrectly uncompress fields
[ https://issues.apache.org/jira/browse/LUCENE-772?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458231#comment-13458231 ] Uwe Schindler commented on LUCENE-772: -- I don't think we need to keep this issue open. It is no longer possible to create compressed fields, Lucene 3.x can only read them. If they are corrupt there is nothing we can do to fix it as this is a bug in JDK. I would close this as won't fix. Index corruption can cause infinite spin loop when Lucene attempts to incorrectly uncompress fields --- Key: LUCENE-772 URL: https://issues.apache.org/jira/browse/LUCENE-772 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 2.1 Environment: Linux (gentoo 2.6.17 at least), jdk 1.5.0_06 and _08 at least, tomcat 5.5. IndexSearcher searching index mounted via NFS; using new lockless commits... We're using the 01-05-07 nightly build of lucene Reporter: Arthur Smith Fix For: 3.6.2 Unfortunately I don't have a reproducible case of this (yet), but it's happened twice now on our production servers in the past few days, after we switched to the new lockless commits (thanks!). What we're seeing is the search thread running away in the middle of a seemingly ordinary search, after several hundred thousand queries that worked just fine. The search index is NFS mounted, and is updated every minute or so during the day by an indexing process running on a separate server. We do get occasional I/O errors, but we catch and retry and it seems ok after a few seconds. But twice now we've had run-away threads; the thread dump in both cases was caught in the middle of java.util.zip.Inflater: http-8080-3 daemon prio=1 tid=0x08294688 nid=0x1f0d runnable [0x1f17c000..0x1f17e0b0] at java.util.zip.Inflater.inflateBytes(Native Method) at java.util.zip.Inflater.inflate(Inflater.java:215) - locked 0x3d73cba8 (a java.util.zip.Inflater) at java.util.zip.Inflater.inflate(Inflater.java:232) at org.apache.lucene.index.FieldsReader.uncompress(FieldsReader.java:388) at org.apache.lucene.index.FieldsReader.addField(FieldsReader.java:222) at org.apache.lucene.index.FieldsReader.doc(FieldsReader.java:105) at org.apache.lucene.index.SegmentReader.document(SegmentReader.java:324) - locked 0x3cefbdd8 (a org.apache.lucene.index.SegmentReader) at org.apache.lucene.index.MultiReader.document(MultiReader.java:108) at org.apache.lucene.index.IndexReader.document(IndexReader.java:360) at org.apache.lucene.search.IndexSearcher.doc(IndexSearcher.java:84) at org.apache.lucene.search.Hits.doc(Hits.java:104) [...] Any ideas what this could be? Thanks! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2544) Add 'divisor' to NumericField, allows for easy storage of full precision data, but indexing *starting* at lower precision.
[ https://issues.apache.org/jira/browse/LUCENE-2544?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13458233#comment-13458233 ] Uwe Schindler commented on LUCENE-2544: --- I agree, this issue will not be fixed as I see no reason to do this. Thanks for closing! Add 'divisor' to NumericField, allows for easy storage of full precision data, but indexing *starting* at lower precision. -- Key: LUCENE-2544 URL: https://issues.apache.org/jira/browse/LUCENE-2544 Project: Lucene - Core Issue Type: Improvement Components: core/other Affects Versions: 3.0.2 Reporter: Woody Anderson Priority: Minor Attachments: LUCENE-2544.patch In some cases, we want to index a timestamp or some other high precision numeric at a much lower precision, but we still want to store the full precision data. Rather than have to do this with two Field objects in the Document, it'd be easier to provide NumericField with a divisor as well as prevision step. The divisor would apply before beginning the trie logic. most often, this is a divide by 1, but that will happen only during the constructor or setXXXValue() in NumericTokenStream. I have the patch for this, or i will after i isolate it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Spatial field names in Solr
How might an average user approach using spatial. In other words, what real world issues and constraints would they be using as guides to sift through these features? I mean, if there is no transparently obvious model to guide average users, you might as well call the field types spatial_alpha, spatial_beta, etc. and users can use folklore and trial and error to decide which types to use, and the full, detailed names need only appear in the field type class attributes. Is there an updated wiki I can look at to understand this stuff a little better? -- Jack Krupansky -Original Message- From: Smiley, David W. Sent: Tuesday, September 18, 2012 5:55 PM To: dev@lucene.apache.org Dev Subject: Spatial field names in Solr This past Sunday I added 3 spatial field types to Solr in SOLR-3304: SpatialTwoDoublesFieldType, SpatialRecursivePrefixTreeFieldType and SpatialTermQueryPrefixTreeFieldType. Eventually there will also be a SpatialBBoxFieldType following this naming convention. These are named in a consistent way based on SpatialStrategy subclasses in the Lucene spatial module. Of course, Solr 3 introduced PointType and LatLonType. What do people think of these Solr field type names? They are kind of long; perhaps the Field parts can be removed. Maybe L4 should precede each of these names? (a Lucene 4 spatial module reference). It would further delineate these fields from the Solr native fields. And about TwoDoubles in particular... I had a tough time coming up with a name for that in the first place as I wanted to avoid a LatLon variation in its name as I think that's a bad idea. For whatever reason I didn't simply choose Point. I opened LUCENE-4374 to rename this SpatialStrategy subclass, suggesting PointVectorStrategy. But maybe PointStrategy is fine. Ideally the name suggests something about its implementation since there very well may be alternative indexing strategies in the future for a given type. ~ David - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Spatial field names in Solr
Hi Jack, Thanks for your interest. Each SpatialStrategy has its pros and cons. I'm working through creating slides for a conference today in fact: http://www.basistech.com/search-conference/presentations/ Now that the Solr adapters are committed, I'll be focusing more on documentation. That means the wiki, and javadoc comments on the SpatialStrategy impls to indicate how each works. ~ David - Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/Spatial-field-names-in-Solr-tp4008769p4008787.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
4.0 issue ping
I noticed today some hanging issues in jira that nobody has touched for a long time set as 4.0. I sent pings to several of these issues: please get them in ASAP or get them out. On friday I plan to push anything not marked as blocker, bug, and assigned to someone out of 4.0 Lets wrap this thing up. -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2329) old index files not deleted on slave
[ https://issues.apache.org/jira/browse/SOLR-2329?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Edwin Khodabakchian updated SOLR-2329: -- Attachment: (was: solrconfig_slave.xml) old index files not deleted on slave Key: SOLR-2329 URL: https://issues.apache.org/jira/browse/SOLR-2329 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 4.0-ALPHA Environment: centos 5.5 ext3 file system Reporter: Edwin Khodabakchian Attachments: solrconfig.xml I have set up index replication (triggered on optimize). The problem I am having is the old index files are not being deleted on the slave. After each replication, I can see the old files still hanging around as well as the files that have just been pulled. This causes the data directory size to increase by the index size every replication until the disk fills up. I am running 4.0 rev 993367 with patch SOLR-1316. Otherwise, the setup is pretty vanilla. I can reproduce this on multiple slaves. Checking the logs, I see the following error: SEVERE: SnapPull failed org.apache.solr.common.SolrException: Index fetch failed : at org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:329) at org.apache.solr.handler.ReplicationHandler.doFetch(ReplicationHandler.java:265) at org.apache.solr.handler.SnapPuller$1.run(SnapPuller.java:159) at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:181) at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:205) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:619) Caused by: org.apache.lucene.store.LockObtainFailedException: Lock obtain timed out: NativeFSLock@/var/solrhome/data/index/lucene-cdaa80c0fefe1a7dfc7aab89298c614c-write.lock at org.apache.lucene.store.Lock.obtain(Lock.java:84) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:1065) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:954) at org.apache.solr.update.SolrIndexWriter.init(SolrIndexWriter.java:192) at org.apache.solr.update.UpdateHandler.createMainIndexWriter(UpdateHandler.java:99) at org.apache.solr.update.DirectUpdateHandler2.openWriter(DirectUpdateHandler2.java:173) at org.apache.solr.update.DirectUpdateHandler2.forceOpenWriter(DirectUpdateHandler2.java:376) at org.apache.solr.handler.SnapPuller.doCommit(SnapPuller.java:471) at org.apache.solr.handler.SnapPuller.fetchLatestIndex(SnapPuller.java:319) ... 11 more lsof reveals that the file is still opened from the java process. Contents of the index data dir: master: -rw-rw-r-- 1 feeddo feeddo 191 Dec 14 01:06 _1lg.fnm -rw-rw-r-- 1 feeddo feeddo 26M Dec 14 01:07 _1lg.fdx -rw-rw-r-- 1 feeddo feeddo 1.9G Dec 14 01:07 _1lg.fdt -rw-rw-r-- 1 feeddo feeddo 474M Dec 14 01:12 _1lg.tis -rw-rw-r-- 1 feeddo feeddo 15M Dec 14 01:12 _1lg.tii -rw-rw-r-- 1 feeddo feeddo 144M Dec 14 01:12 _1lg.prx -rw-rw-r-- 1 feeddo feeddo 277M Dec 14 01:12 _1lg.frq -rw-rw-r-- 1 feeddo feeddo 311 Dec 14 01:12 segments_1ji -rw-rw-r-- 1 feeddo feeddo 23M Dec 14 01:12 _1lg.nrm -rw-rw-r-- 1 feeddo feeddo 191 Dec 18 01:11 _24e.fnm -rw-rw-r-- 1 feeddo feeddo 26M Dec 18 01:12 _24e.fdx -rw-rw-r-- 1 feeddo feeddo 1.9G Dec 18 01:12 _24e.fdt -rw-rw-r-- 1 feeddo feeddo 483M Dec 18 01:23 _24e.tis -rw-rw-r-- 1 feeddo feeddo 15M Dec 18 01:23 _24e.tii -rw-rw-r-- 1 feeddo feeddo 146M Dec 18 01:23 _24e.prx -rw-rw-r-- 1 feeddo feeddo 283M Dec 18 01:23 _24e.frq -rw-rw-r-- 1 feeddo feeddo 311 Dec 18 01:24 segments_1xz -rw-rw-r-- 1 feeddo feeddo 23M Dec 18 01:24 _24e.nrm -rw-rw-r-- 1 feeddo feeddo 191 Dec 18 13:15 _25z.fnm -rw-rw-r-- 1 feeddo feeddo 26M Dec 18 13:16 _25z.fdx -rw-rw-r-- 1 feeddo feeddo 1.9G Dec 18 13:16 _25z.fdt -rw-rw-r-- 1 feeddo feeddo 484M Dec 18 13:35 _25z.tis -rw-rw-r-- 1 feeddo feeddo 15M Dec 18 13:35 _25z.tii -rw-rw-r-- 1 feeddo feeddo 146M Dec 18 13:35 _25z.prx -rw-rw-r-- 1 feeddo feeddo 284M Dec 18 13:35 _25z.frq -rw-rw-r-- 1 feeddo feeddo 20 Dec 18 13:35 segments.gen -rw-rw-r-- 1 feeddo feeddo 311 Dec
