date:20130131


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

Dawid Weiss commented on LUCENE-4736:
-

I have tried on two different machines with the latest J9 distributions but I 
couldn't reproduce this.

{code}
java version 1.6.0
Java(TM) SE Runtime Environment (build pxa6460sr12-20121025_01(SR12))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
jvmxa6460sr12-20121024_126067 (JIT enabled, AOT enabled)
J9VM - 20121024_126067
JIT  - r9_20120914_26057
GC   - 20120928_AA)
JCL  - 20121014_01
{code}

{code}
java version 1.7.0
Java(TM) SE Runtime Environment (build pxa6470sr2-20120901_01(SR2))
IBM J9 VM (build 2.6, JRE 1.7.0 Linux amd64-64 20120809_118929 (JIT enabled, 
AOT enabled)
J9VM - R26_Java726_SR2_20120809_0948_B118929
JIT  - r11.b01_20120808_24925
GC   - R26_Java726_SR2_20120809_0948_B118929
J9CL - 20120809_118929)
JCL - 20120831_02 based on Oracle 7u3-b05
{code}

Your JVM ID looks kind of spooky -- perhaps it's something related to the 
particular distro that you have?

 Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be 
 killed
 

 Key: LUCENE-4736
 URL: https://issues.apache.org/jira/browse/LUCENE-4736
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless

 EG:
 {noformat}
 ant test -Dtestcase=TestIndexWriterDelete -Dtests.seed=A22BC3E06CEC0036
 {noformat}
 Takes a while and then fails with this:
 {noformat}
 [junit4:junit4] ERROR   0.00s J2 | TestIndexWriterDelete (suite) 
 [junit4:junit4] Throwable #1:
 com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked
 from SUITE scope at org.apache.lucene.index.TestIndexWriterDelete:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 [junit4:junit4] Throwable #2:
 com.carrotsearch.randomizedtesting.ThreadLeakError: There are still
 zombie threads that couldn't be terminated:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 {noformat}
 Java version is:
 {noformat}
 java version 1.6.0
 Java(TM) SE Runtime Environment (build pxa6460sr9fp2ifix-2011_05(SR9 
 FP2+IV03622+IV02378+IZ99243+IZ97310+IV00707))
 IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
 jvmxa6460sr9-2011_94827 (JIT enabled, AOT enabled)
 J9VM - 2011_094827
 JIT  - r9_20101028_17488ifx45
 GC   - 20101027_AA)
 JCL  - 20110727_04
 {noformat}
 Curiously, I think it tends to happen on a test that fails an assumption?  Or 
 maybe I'm just imagining that ...

--
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-4737) Who tests the tester tests sometimes fail under IBM J9


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

Dawid Weiss commented on LUCENE-4737:
-

You don't see the reproduce line because they are not tests that extend from 
LuceneTest* base - they cannot be because this class cannot run recursively 
nested. I'm looking.

 Who tests the tester tests sometimes fail under IBM J9
 

 Key: LUCENE-4737
 URL: https://issues.apache.org/jira/browse/LUCENE-4737
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless

 Curiously, the tests only seem to fail when I run ant test from 
 lucene/core.  No Reproduce with line is printed ... and if I run the 
 failing tests alone, they do not fail.
 The failures look like this:
 {noformat}
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed
 [junit4:junit4] FAILURE 0.02s J2 | 
 TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed 
 [junit4:junit4] Throwable #1: java.lang.AssertionError: expected:1 but 
 was:0
 [junit4:junit4]  at org.junit.Assert.fail(Assert.java:93)
 [junit4:junit4]  at org.junit.Assert.failNotEquals(Assert.java:647)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:128)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:472)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:456)
 [junit4:junit4]  at 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed(TestFailIfDirectoryNotClosed.java:41)
 [junit4:junit4]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
 Method)
 [junit4:junit4]  at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
 [junit4:junit4]  at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
 [junit4:junit4]  at java.lang.reflect.Method.invoke(Method.java:611)
 [junit4:junit4]  at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
 [junit4:junit4]  at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 [junit4:junit4]  at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
 [junit4:junit4]  at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
 [junit4:junit4]  at org.junit.rules.RunRules.evaluate(RunRules.java:18)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
 [junit4:junit4]  at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
 [junit4:junit4]  at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.run(ParentRunner.java:300)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:180)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:275)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
 [junit4:junit4] Completed on J2 in 0.02s, 1 test, 1 failure  FAILURES!
 {noformat}
 And at the end of ant test I see:
 {noformat}
 [junit4:junit4] Tests with failures (first 10 out of 34):
 [junit4:junit4]   - org.apache.lucene.store.TestLockFactory (suite)
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestCodecReported.testCorrectCodecReported
 [junit4:junit4]   - org.apache.lucene.index.TestIndexWriterReader (suite)
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining.testSetupChaining
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining.testTeardownChaining
 [junit4:junit4]   -

[jira] [Commented] (LUCENE-4737) Who tests the tester tests sometimes fail under IBM J9


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

Dawid Weiss commented on LUCENE-4737:
-

Mike I've committed a patch that should display the cause of these in revision 
1440882 (on trunk). Could you re-run and attach the execution log? I think the 
root of the problem is those thread leaks which I cannot reproduce but which 
will cause false failures in those tests (because they run a nested test and 
don't expect any unusual issues with it).

 Who tests the tester tests sometimes fail under IBM J9
 

 Key: LUCENE-4737
 URL: https://issues.apache.org/jira/browse/LUCENE-4737
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless

 Curiously, the tests only seem to fail when I run ant test from 
 lucene/core.  No Reproduce with line is printed ... and if I run the 
 failing tests alone, they do not fail.
 The failures look like this:
 {noformat}
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed
 [junit4:junit4] FAILURE 0.02s J2 | 
 TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed 
 [junit4:junit4] Throwable #1: java.lang.AssertionError: expected:1 but 
 was:0
 [junit4:junit4]  at org.junit.Assert.fail(Assert.java:93)
 [junit4:junit4]  at org.junit.Assert.failNotEquals(Assert.java:647)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:128)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:472)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:456)
 [junit4:junit4]  at 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed(TestFailIfDirectoryNotClosed.java:41)
 [junit4:junit4]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
 Method)
 [junit4:junit4]  at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
 [junit4:junit4]  at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
 [junit4:junit4]  at java.lang.reflect.Method.invoke(Method.java:611)
 [junit4:junit4]  at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
 [junit4:junit4]  at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 [junit4:junit4]  at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
 [junit4:junit4]  at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
 [junit4:junit4]  at org.junit.rules.RunRules.evaluate(RunRules.java:18)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
 [junit4:junit4]  at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
 [junit4:junit4]  at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.run(ParentRunner.java:300)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:180)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:275)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
 [junit4:junit4] Completed on J2 in 0.02s, 1 test, 1 failure  FAILURES!
 {noformat}
 And at the end of ant test I see:
 {noformat}
 [junit4:junit4] Tests with failures (first 10 out of 34):
 [junit4:junit4]   - org.apache.lucene.store.TestLockFactory (suite)
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestCodecReported.testCorrectCodecReported
 [junit4:junit4]   - org.apache.lucene.index.TestIndexWriterReader (suite)
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed
 [junit4:junit4]   -

[jira] [Commented] (LUCENE-4737) Who tests the tester tests sometimes fail under IBM J9


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

Commit Tag Bot commented on LUCENE-4737:


[trunk commit] Dawid Weiss
http://svn.apache.org/viewvc?view=revisionrevision=1440882

LUCENE-4737: be more verbose and print stdout/stderr when a nested test fails. 
I suspect all these are related to thread leaks on J9 which I cannot reproduce 
but this should reveal the cause of the problem.


 Who tests the tester tests sometimes fail under IBM J9
 

 Key: LUCENE-4737
 URL: https://issues.apache.org/jira/browse/LUCENE-4737
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless

 Curiously, the tests only seem to fail when I run ant test from 
 lucene/core.  No Reproduce with line is printed ... and if I run the 
 failing tests alone, they do not fail.
 The failures look like this:
 {noformat}
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed
 [junit4:junit4] FAILURE 0.02s J2 | 
 TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed 
 [junit4:junit4] Throwable #1: java.lang.AssertionError: expected:1 but 
 was:0
 [junit4:junit4]  at org.junit.Assert.fail(Assert.java:93)
 [junit4:junit4]  at org.junit.Assert.failNotEquals(Assert.java:647)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:128)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:472)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:456)
 [junit4:junit4]  at 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed(TestFailIfDirectoryNotClosed.java:41)
 [junit4:junit4]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
 Method)
 [junit4:junit4]  at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
 [junit4:junit4]  at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
 [junit4:junit4]  at java.lang.reflect.Method.invoke(Method.java:611)
 [junit4:junit4]  at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
 [junit4:junit4]  at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 [junit4:junit4]  at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
 [junit4:junit4]  at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
 [junit4:junit4]  at org.junit.rules.RunRules.evaluate(RunRules.java:18)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
 [junit4:junit4]  at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
 [junit4:junit4]  at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.run(ParentRunner.java:300)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:180)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:275)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
 [junit4:junit4] Completed on J2 in 0.02s, 1 test, 1 failure  FAILURES!
 {noformat}
 And at the end of ant test I see:
 {noformat}
 [junit4:junit4] Tests with failures (first 10 out of 34):
 [junit4:junit4]   - org.apache.lucene.store.TestLockFactory (suite)
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestCodecReported.testCorrectCodecReported
 [junit4:junit4]   - org.apache.lucene.index.TestIndexWriterReader (suite)
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining.testSetupChaining
 [junit4:junit4]   -

[jira] [Commented] (SOLR-4384) Make post.jar report timing information


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

Commit Tag Bot commented on SOLR-4384:
--

[trunk commit] Jan Høydahl
http://svn.apache.org/viewvc?view=revisionrevision=1440899

SOLR-4384: Simplify time print using SimpleDateFormat


 Make post.jar report timing information
 ---

 Key: SOLR-4384
 URL: https://issues.apache.org/jira/browse/SOLR-4384
 Project: Solr
  Issue Type: Improvement
  Components: scripts and tools
Reporter: Upayavira
Assignee: Jan Høydahl
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: SOLR-4384.patch


 post.jar can be used to push reasonable amounts of content to Solr. It can be 
 useful to know how long a post took if evaluating simple index time 
 performance improvements when new to using Solr.

--
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-4739) FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes


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

Commit Tag Bot commented on LUCENE-4739:


[trunk commit] Adrien Grand
http://svn.apache.org/viewvc?view=revisionrevision=1440909

LUCENE-4739: Fix integer overflow in Packed64.get/set.



 FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes
 

 Key: LUCENE-4739
 URL: https://issues.apache.org/jira/browse/LUCENE-4739
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4739.patch


 This is really quite awful, but the test I created for  2.1 GB FSTs never 
 tested save/load ... and ... it doesn't work.

--
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-4384) Make post.jar report timing information


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

Commit Tag Bot commented on SOLR-4384:
--

[branch_4x commit] Jan Høydahl
http://svn.apache.org/viewvc?view=revisionrevision=1440910

SOLR-4384: Simplify time print using SimpleDateFormat


 Make post.jar report timing information
 ---

 Key: SOLR-4384
 URL: https://issues.apache.org/jira/browse/SOLR-4384
 Project: Solr
  Issue Type: Improvement
  Components: scripts and tools
Reporter: Upayavira
Assignee: Jan Høydahl
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: SOLR-4384.patch


 post.jar can be used to push reasonable amounts of content to Solr. It can be 
 useful to know how long a post took if evaluating simple index time 
 performance improvements when new to using Solr.

--
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-4737) Who tests the tester tests sometimes fail under IBM J9


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

Michael McCandless updated LUCENE-4737:
---

Attachment: j9log.txt

OK I re-ran ant test after updating, in lucene/core ... attaching full output.

 Who tests the tester tests sometimes fail under IBM J9
 

 Key: LUCENE-4737
 URL: https://issues.apache.org/jira/browse/LUCENE-4737
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Attachments: j9log.txt


 Curiously, the tests only seem to fail when I run ant test from 
 lucene/core.  No Reproduce with line is printed ... and if I run the 
 failing tests alone, they do not fail.
 The failures look like this:
 {noformat}
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed
 [junit4:junit4] FAILURE 0.02s J2 | 
 TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed 
 [junit4:junit4] Throwable #1: java.lang.AssertionError: expected:1 but 
 was:0
 [junit4:junit4]  at org.junit.Assert.fail(Assert.java:93)
 [junit4:junit4]  at org.junit.Assert.failNotEquals(Assert.java:647)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:128)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:472)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:456)
 [junit4:junit4]  at 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed(TestFailIfDirectoryNotClosed.java:41)
 [junit4:junit4]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
 Method)
 [junit4:junit4]  at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
 [junit4:junit4]  at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
 [junit4:junit4]  at java.lang.reflect.Method.invoke(Method.java:611)
 [junit4:junit4]  at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
 [junit4:junit4]  at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 [junit4:junit4]  at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
 [junit4:junit4]  at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
 [junit4:junit4]  at org.junit.rules.RunRules.evaluate(RunRules.java:18)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
 [junit4:junit4]  at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
 [junit4:junit4]  at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.run(ParentRunner.java:300)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:180)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:275)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
 [junit4:junit4] Completed on J2 in 0.02s, 1 test, 1 failure  FAILURES!
 {noformat}
 And at the end of ant test I see:
 {noformat}
 [junit4:junit4] Tests with failures (first 10 out of 34):
 [junit4:junit4]   - org.apache.lucene.store.TestLockFactory (suite)
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestCodecReported.testCorrectCodecReported
 [junit4:junit4]   - org.apache.lucene.index.TestIndexWriterReader (suite)
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining.testSetupChaining
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining.testTeardownChaining
 [junit4:junit4]   - 
 org.apache.lucene.codecs.compressing.TestCompressingStoredFieldsFormat (suite)
 [junit4:junit4]   -

[jira] [Created] (SOLR-4391) Dataimport UI defaults should reflect the documented statess

2013-01-31 Thread Ota Mares (JIRA)

Ota Mares created SOLR-4391:
---

 Summary: Dataimport UI defaults should reflect the documented 
statess
 Key: SOLR-4391
 URL: https://issues.apache.org/jira/browse/SOLR-4391
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0
Reporter: Ota Mares
Priority: Minor


The [wiki|http://wiki.apache.org/solr/DataImportHandler#Commands] states that 
some dataimport commands are enabled by default. These states should be 
reflected in the web ui because currently it leads to confusions if the 
commands are enabled or not.

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

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

[jira] [Updated] (SOLR-4391) Dataimport UI defaults should reflect the documented states

2013-01-31 Thread Ota Mares (JIRA)


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

Ota Mares updated SOLR-4391:


Summary: Dataimport UI defaults should reflect the documented states  (was: 
Dataimport UI defaults should reflect the documented statess)

 Dataimport UI defaults should reflect the documented states
 ---

 Key: SOLR-4391
 URL: https://issues.apache.org/jira/browse/SOLR-4391
 Project: Solr
  Issue Type: Improvement
  Components: web gui
Affects Versions: 4.0
Reporter: Ota Mares
Priority: Minor

 The [wiki|http://wiki.apache.org/solr/DataImportHandler#Commands] states that 
 some dataimport commands are enabled by default. These states should be 
 reflected in the web ui because currently it leads to confusions if the 
 commands are enabled or not.

--
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-2827) RegexpBoost Update Processor


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

Commit Tag Bot commented on SOLR-2827:
--

[trunk commit] Jan Høydahl
http://svn.apache.org/viewvc?view=revisionrevision=1440940

SOLR-2827: RegexpBoost Update Processor


 RegexpBoost Update Processor
 

 Key: SOLR-2827
 URL: https://issues.apache.org/jira/browse/SOLR-2827
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
  Labels: UpdateProcessor
 Fix For: 4.2, 5.0

 Attachments: SOLR-2827.patch, SOLR-2827.patch


 Processor which reads a string field and outputs a float field with a boost 
 value if the input string matched one of several RegEx.
 The processor reads a separate file with one RegEx per line with associated 
 boost value.
 We used it to (de)boost web pages based on URL patterns. Could be used for 
 many other use cases as well
 Kindly donated by Oslo University

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

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

[jira] [Assigned] (LUCENE-4737) Who tests the tester tests sometimes fail under IBM J9


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

Dawid Weiss reassigned LUCENE-4737:
---

Assignee: Dawid Weiss

 Who tests the tester tests sometimes fail under IBM J9
 

 Key: LUCENE-4737
 URL: https://issues.apache.org/jira/browse/LUCENE-4737
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Dawid Weiss
 Attachments: j9log.txt


 Curiously, the tests only seem to fail when I run ant test from 
 lucene/core.  No Reproduce with line is printed ... and if I run the 
 failing tests alone, they do not fail.
 The failures look like this:
 {noformat}
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed
 [junit4:junit4] FAILURE 0.02s J2 | 
 TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed 
 [junit4:junit4] Throwable #1: java.lang.AssertionError: expected:1 but 
 was:0
 [junit4:junit4]  at org.junit.Assert.fail(Assert.java:93)
 [junit4:junit4]  at org.junit.Assert.failNotEquals(Assert.java:647)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:128)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:472)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:456)
 [junit4:junit4]  at 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed(TestFailIfDirectoryNotClosed.java:41)
 [junit4:junit4]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
 Method)
 [junit4:junit4]  at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
 [junit4:junit4]  at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
 [junit4:junit4]  at java.lang.reflect.Method.invoke(Method.java:611)
 [junit4:junit4]  at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
 [junit4:junit4]  at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 [junit4:junit4]  at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
 [junit4:junit4]  at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
 [junit4:junit4]  at org.junit.rules.RunRules.evaluate(RunRules.java:18)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
 [junit4:junit4]  at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
 [junit4:junit4]  at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.run(ParentRunner.java:300)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:180)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:275)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
 [junit4:junit4] Completed on J2 in 0.02s, 1 test, 1 failure  FAILURES!
 {noformat}
 And at the end of ant test I see:
 {noformat}
 [junit4:junit4] Tests with failures (first 10 out of 34):
 [junit4:junit4]   - org.apache.lucene.store.TestLockFactory (suite)
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestCodecReported.testCorrectCodecReported
 [junit4:junit4]   - org.apache.lucene.index.TestIndexWriterReader (suite)
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining.testSetupChaining
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining.testTeardownChaining
 [junit4:junit4]   - 
 org.apache.lucene.codecs.compressing.TestCompressingStoredFieldsFormat (suite)
 [junit4:junit4]   -

[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module


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

Kai Gülzau commented on LUCENE-2899:


The patch seems to be a bit out of date.
Applying it to branch_4x or trunk fails (build scripts).

 Add OpenNLP Analysis capabilities as a module
 -

 Key: LUCENE-2899
 URL: https://issues.apache.org/jira/browse/LUCENE-2899
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
 LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, OpenNLPFilter.java, 
 OpenNLPTokenizer.java, opennlp_trunk.patch


 Now that OpenNLP is an ASF project and has a nice license, it would be nice 
 to have a submodule (under analysis) that exposed capabilities for it. Drew 
 Farris, Tom Morton and I have code that does:
 * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
 would have to change slightly to buffer tokens)
 * NamedEntity recognition as a TokenFilter
 We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
 either payloads (PartOfSpeechAttribute?) on a token or at the same position.
 I'd propose it go under:
 modules/analysis/opennlp

--
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-2827) RegexpBoost Update Processor


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

Jan Høydahl resolved SOLR-2827.
---

Resolution: Fixed

 RegexpBoost Update Processor
 

 Key: SOLR-2827
 URL: https://issues.apache.org/jira/browse/SOLR-2827
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
  Labels: UpdateProcessor
 Fix For: 4.2, 5.0

 Attachments: SOLR-2827.patch, SOLR-2827.patch


 Processor which reads a string field and outputs a float field with a boost 
 value if the input string matched one of several RegEx.
 The processor reads a separate file with one RegEx per line with associated 
 boost value.
 We used it to (de)boost web pages based on URL patterns. Could be used for 
 many other use cases as well
 Kindly donated by Oslo University

--
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-4739) FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes

2013-01-31 Thread Adrien Grand (JIRA)


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

Adrien Grand resolved LUCENE-4739.
--

Resolution: Fixed
  Assignee: Adrien Grand

Fixed. This was due to an int overflow in Packed64's bulk get and set methods. 
Thanks Mike!

 FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes
 

 Key: LUCENE-4739
 URL: https://issues.apache.org/jira/browse/LUCENE-4739
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Adrien Grand
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4739.patch


 This is really quite awful, but the test I created for  2.1 GB FSTs never 
 tested save/load ... and ... it doesn't work.

--
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-2827) RegexpBoost Update Processor


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

Commit Tag Bot commented on SOLR-2827:
--

[branch_4x commit] Jan Høydahl
http://svn.apache.org/viewvc?view=revisionrevision=1440944

SOLR-2827: RegexpBoost Update Processor


 RegexpBoost Update Processor
 

 Key: SOLR-2827
 URL: https://issues.apache.org/jira/browse/SOLR-2827
 Project: Solr
  Issue Type: New Feature
  Components: update
Reporter: Jan Høydahl
Assignee: Jan Høydahl
  Labels: UpdateProcessor
 Fix For: 4.2, 5.0

 Attachments: SOLR-2827.patch, SOLR-2827.patch


 Processor which reads a string field and outputs a float field with a boost 
 value if the input string matched one of several RegEx.
 The processor reads a separate file with one RegEx per line with associated 
 boost value.
 We used it to (de)boost web pages based on URL patterns. Could be used for 
 many other use cases as well
 Kindly donated by Oslo University

--
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-4731) New ReplicatingDirectory mirrors index files to HDFS

2013-01-31 Thread David Arthur (JIRA)

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

David Arthur commented on LUCENE-4731:
--

bq. all other processes are stopped until it finishes

Not exactly, just no other replication or delete events will happen

bq. Take a snapshot on the index, so those files that it copies won't get
deleted for sure.

Is that what the SnapshotDeletionPolicy does? This does sound more robust than
watching for segments.gen - where can I see it in use? Is this what Solr uses
for replication?

What would be a recommended mechanism for receiving push requests from a
remote agent? Does lucene have any kind of RPC server like Thrift built-in (I
imagine not).

New ReplicatingDirectory mirrors index files to HDFS

Key: LUCENE-4731
URL: https://issues.apache.org/jira/browse/LUCENE-4731
Project: Lucene - Core
Issue Type: New Feature
Components: core/store
Reporter: David Arthur
Fix For: 4.2, 5.0

Attachments: ReplicatingDirectory.java

I've been working on a Directory implementation that mirrors the index files
to HDFS (or other Hadoop supported FileSystem).
A ReplicatingDirectory delegates all calls to an underlying Directory
(supplied in the constructor). The only hooks are the deleteFile and sync
calls. We submit deletes and replications to a single scheduler thread to
keep things serializer. During a sync call, if segments.gen is seen in the
list of files, we know a commit is finishing. After calling the deletage's
sync method, we initialize an asynchronous replication as follows.
* Read segments.gen (before leaving ReplicatingDirectory#sync), save the
values for later
* Get a list of local files from ReplicatingDirectory#listAll before leaving
ReplicatingDirectory#sync
* Submit replication task (DirectoryReplicator) to scheduler thread
* Compare local files to remote files, determine which remote files get
deleted, and which need to get copied
* Submit a thread to copy each file (one thead per file)
* Submit a thread to delete each file (one thead per file)
* Submit a finalizer thread. This thread waits on the previous two batches
of threads to finish. Once finished, this thread generates a new
segments.gen remotely (using the version and generation number previously
read in).
I have no idea where this would belong in the Lucene project, so i'll just
attach the standalone class instead of a patch. It introduces dependencies on
Hadoop core (and all the deps that brings with 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-4739) FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes


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

Commit Tag Bot commented on LUCENE-4739:


[branch_4x commit] Adrien Grand
http://svn.apache.org/viewvc?view=revisionrevision=1440949

LUCENE-4739: Fix integer overflow in Packed64.get/set (merged from r1440909).



 FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes
 

 Key: LUCENE-4739
 URL: https://issues.apache.org/jira/browse/LUCENE-4739
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Adrien Grand
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4739.patch


 This is really quite awful, but the test I created for  2.1 GB FSTs never 
 tested save/load ... and ... it doesn't work.

--
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-4736) Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be killed


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

Dawid Weiss commented on LUCENE-4736:
-

It's one of those things that you just cannot predict. Ever.
{code}
[14:16:48.627] OK  0.10s | TestIndexWriterDelete.testDeleteAll
  1 Timer created by: 
Thread[SUITE-TestIndexWriterDelete-seed#[A22BC3E06CEC0036]-worker,5,TGRP-TestIndexWriterDelete]
  2 java.lang.Exception
  2at java.util.Timer$TimerImpl.init(Timer.java:189)
  2at java.util.Timer.init(Timer.java:355)
  2at 
java.util.prefs.FileSystemPreferences.clinit(FileSystemPreferences.java:424)
  2at java.lang.J9VMInternals.initializeImpl(Native Method)
  2at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
  2at 
java.util.prefs.FileSystemPreferencesFactory.userRoot(FileSystemPreferencesFactory.java:35)
  2at java.util.prefs.Preferences.userRoot(Preferences.java:445)
  2at java.util.prefs.Preferences.userNodeForPackage(Preferences.java:359)
  2at 
com.ibm.crypto.pkcs11impl.provider.IBMPKCS11Impl.init(IBMPKCS11Impl.java:612)
  2at java.lang.J9VMInternals.newInstanceImpl(Native Method)
  2at java.lang.Class.newInstance(Class.java:1345)
  2at 
org.apache.harmony.security.fortress.Services$1.run(Services.java:1116)
  2at 
org.apache.harmony.security.fortress.Services$1.run(Services.java:1113)
  2at 
java.security.AccessController.doPrivileged(AccessController.java:202)
  2at 
org.apache.harmony.security.fortress.Services.newInstance(Services.java:1113)
  2at 
org.apache.harmony.security.fortress.Services.access$800(Services.java:56)
  2at 
org.apache.harmony.security.fortress.Services$NormalServices.createProviderInstance(Services.java:342)
  2at 
org.apache.harmony.security.fortress.Services$NormalServices.createExtProviderInstance(Services.java:320)
  2at 
org.apache.harmony.security.fortress.Services$NormalServices.access$1200(Services.java:160)
  2at 
org.apache.harmony.security.fortress.Services$NormalServices$3.run(Services.java:595)
  2at 
java.security.AccessController.doPrivileged(AccessController.java:202)
  2at 
org.apache.harmony.security.fortress.Services$NormalServices.loadExtProviders(Services.java:571)
  2at 
org.apache.harmony.security.fortress.Services$NormalServices.access$300(Services.java:160)
  2at 
org.apache.harmony.security.fortress.Services$NormalServices$1.run(Services.java:203)
  2at 
java.security.AccessController.doPrivileged(AccessController.java:202)
  2at 
org.apache.harmony.security.fortress.Services$NormalServices.clinit(Services.java:198)
  2at java.lang.J9VMInternals.initializeImpl(Native Method)
  2at java.lang.J9VMInternals.initialize(J9VMInternals.java:200)
  2at 
org.apache.harmony.security.fortress.Services.refresh(Services.java:1074)
  2at 
org.apache.harmony.security.fortress.Engine.getInstance(Engine.java:127)
  2at java.security.MessageDigest.getInstance(MessageDigest.java:75)
  2at 
java.io.ObjectStreamClass.computeDefaultSUID(ObjectStreamClass.java:1829)
  2at java.io.ObjectStreamClass.access$100(ObjectStreamClass.java:64)
  2at java.io.ObjectStreamClass$1.run(ObjectStreamClass.java:220)
  2at 
java.security.AccessController.doPrivileged(AccessController.java:202)
  2at 
java.io.ObjectStreamClass.getSerialVersionUID(ObjectStreamClass.java:217)
  2at java.io.ObjectStreamClass.writeNonProxy(ObjectStreamClass.java:737)
  2at 
java.io.ObjectOutputStream.writeClassDescriptor(ObjectOutputStream.java:665)
  2at 
java.io.ObjectOutputStream.writeNonProxyDesc(ObjectOutputStream.java:1273)
  2at 
java.io.ObjectOutputStream.writeClassDesc(ObjectOutputStream.java:1231)
  2at java.io.ObjectOutputStream.writeArray(ObjectOutputStream.java:1310)
  2at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1174)
  2at 
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1537)
  2at 
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1502)
  2at 
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1420)
  2at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
  2at 
java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1537)
  2at 
java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1502)
  2at 
java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1420)
  2at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
  2at java.io.ObjectOutputStream.writeObject(ObjectOutputStream.java:347)
  2at 
com.carrotsearch.ant.tasks.junit4.events.mirrors.SerializableMirror.tryToSerialize(SerializableMirror.java:41)
  2at 
com.carrotsearch.ant.tasks.junit4.events.mirrors.SerializableMirror.init(SerializableMirror.java:16)
  2

[jira] [Commented] (LUCENE-4731) New ReplicatingDirectory mirrors index files to HDFS

2013-01-31 Thread Shai Erera (JIRA)

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

Shai Erera commented on LUCENE-4731:

bq. Not exactly, just no other replication or delete events will happen

Well in that case then you could run into troubles. I.e. imagine two threads,
one doing commit() and one doing replication. The commit() thread could be much
faster than the replication one. Therefore, it can do commit(#1), replication
thread starts to replication that index commit. In the middle, the commit
thread does commit(#2), which deletes some files of the previous commit (e.g.
due to segment merging), and the replication thread will be left with a corrupt
commit ...

bq. Is that what the SnapshotDeletionPolicy does

Yes. You can see how it's used in the tests. Also, here's a thread from the
user list with an example code: http://markmail.org/message/3novogsi6vcgarur.

I am not sure if Solr uses it, but I think it does. I mean .. it's the safe
way to replicate/backup your index.

Lucene doesn't have an RPC server built-in .. I wrote a simple Servlet that
responds to some REST API to invoke replication ...

New ReplicatingDirectory mirrors index files to HDFS

Key: LUCENE-4731
URL: https://issues.apache.org/jira/browse/LUCENE-4731
Project: Lucene - Core
Issue Type: New Feature
Components: core/store
Reporter: David Arthur
Fix For: 4.2, 5.0

Attachments: ReplicatingDirectory.java

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

[jira] [Commented] (SOLR-3013) Add UIMA based tokenizers / filters that can be used in the schema.xml


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

Kai Gülzau commented on SOLR-3013:
--

http://wiki.apache.org/solr/SolrUIMA is not mentioning these 
analyzers/tokenizers.
Is there any documentation how to use these?

 Add UIMA based tokenizers / filters that can be used in the schema.xml
 --

 Key: SOLR-3013
 URL: https://issues.apache.org/jira/browse/SOLR-3013
 Project: Solr
  Issue Type: Improvement
  Components: update
Reporter: Tommaso Teofili
Assignee: Tommaso Teofili
Priority: Minor
  Labels: uima, update_request_handler
 Fix For: 4.0-ALPHA

 Attachments: SOLR-3013.patch


 Add UIMA based tokenizers / filters that can be declared and used directly 
 inside the schema.xml.
 Thus instead of using the UIMA UpdateRequestProcessor one could directly 
 define per-field NLP capable tokenizers / filters.

--
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-4736) Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be killed


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

Commit Tag Bot commented on LUCENE-4736:


[trunk commit] Dawid Weiss
http://svn.apache.org/viewvc?view=revisionrevision=1440961

LUCENE-4736: ignore TimerThread zombies on J9.


 Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be 
 killed
 

 Key: LUCENE-4736
 URL: https://issues.apache.org/jira/browse/LUCENE-4736
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless

 EG:
 {noformat}
 ant test -Dtestcase=TestIndexWriterDelete -Dtests.seed=A22BC3E06CEC0036
 {noformat}
 Takes a while and then fails with this:
 {noformat}
 [junit4:junit4] ERROR   0.00s J2 | TestIndexWriterDelete (suite) 
 [junit4:junit4] Throwable #1:
 com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked
 from SUITE scope at org.apache.lucene.index.TestIndexWriterDelete:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 [junit4:junit4] Throwable #2:
 com.carrotsearch.randomizedtesting.ThreadLeakError: There are still
 zombie threads that couldn't be terminated:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 {noformat}
 Java version is:
 {noformat}
 java version 1.6.0
 Java(TM) SE Runtime Environment (build pxa6460sr9fp2ifix-2011_05(SR9 
 FP2+IV03622+IV02378+IZ99243+IZ97310+IV00707))
 IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
 jvmxa6460sr9-2011_94827 (JIT enabled, AOT enabled)
 J9VM - 2011_094827
 JIT  - r9_20101028_17488ifx45
 GC   - 20101027_AA)
 JCL  - 20110727_04
 {noformat}
 Curiously, I think it tends to happen on a test that fails an assumption?  Or 
 maybe I'm just imagining that ...

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

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

[jira] [Assigned] (LUCENE-4736) Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be killed


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

Dawid Weiss reassigned LUCENE-4736:
---

Assignee: Dawid Weiss

 Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be 
 killed
 

 Key: LUCENE-4736
 URL: https://issues.apache.org/jira/browse/LUCENE-4736
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Dawid Weiss

 EG:
 {noformat}
 ant test -Dtestcase=TestIndexWriterDelete -Dtests.seed=A22BC3E06CEC0036
 {noformat}
 Takes a while and then fails with this:
 {noformat}
 [junit4:junit4] ERROR   0.00s J2 | TestIndexWriterDelete (suite) 
 [junit4:junit4] Throwable #1:
 com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked
 from SUITE scope at org.apache.lucene.index.TestIndexWriterDelete:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 [junit4:junit4] Throwable #2:
 com.carrotsearch.randomizedtesting.ThreadLeakError: There are still
 zombie threads that couldn't be terminated:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 {noformat}
 Java version is:
 {noformat}
 java version 1.6.0
 Java(TM) SE Runtime Environment (build pxa6460sr9fp2ifix-2011_05(SR9 
 FP2+IV03622+IV02378+IZ99243+IZ97310+IV00707))
 IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
 jvmxa6460sr9-2011_94827 (JIT enabled, AOT enabled)
 J9VM - 2011_094827
 JIT  - r9_20101028_17488ifx45
 GC   - 20101027_AA)
 JCL  - 20110727_04
 {noformat}
 Curiously, I think it tends to happen on a test that fails an assumption?  Or 
 maybe I'm just imagining that ...

--
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-4736) Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be killed


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

Dawid Weiss commented on LUCENE-4736:
-

I've hacked around a filter for J9. It's the simplest solution I guess. Mike, 
could you check? It went fine for me. If it's ok we need to backport to 4.x 
probably.

 Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be 
 killed
 

 Key: LUCENE-4736
 URL: https://issues.apache.org/jira/browse/LUCENE-4736
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Dawid Weiss

 EG:
 {noformat}
 ant test -Dtestcase=TestIndexWriterDelete -Dtests.seed=A22BC3E06CEC0036
 {noformat}
 Takes a while and then fails with this:
 {noformat}
 [junit4:junit4] ERROR   0.00s J2 | TestIndexWriterDelete (suite) 
 [junit4:junit4] Throwable #1:
 com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked
 from SUITE scope at org.apache.lucene.index.TestIndexWriterDelete:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 [junit4:junit4] Throwable #2:
 com.carrotsearch.randomizedtesting.ThreadLeakError: There are still
 zombie threads that couldn't be terminated:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 {noformat}
 Java version is:
 {noformat}
 java version 1.6.0
 Java(TM) SE Runtime Environment (build pxa6460sr9fp2ifix-2011_05(SR9 
 FP2+IV03622+IV02378+IZ99243+IZ97310+IV00707))
 IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
 jvmxa6460sr9-2011_94827 (JIT enabled, AOT enabled)
 J9VM - 2011_094827
 JIT  - r9_20101028_17488ifx45
 GC   - 20101027_AA)
 JCL  - 20110727_04
 {noformat}
 Curiously, I think it tends to happen on a test that fails an assumption?  Or 
 maybe I'm just imagining that ...

--
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-4381) Query-time multi-word synonym expansion

2013-01-31 Thread Nolan Lawson (JIRA)

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

Nolan Lawson commented on SOLR-4381:

Absolutely right, Jan. software foundation apache, foundation software
apache, and any other combination all match. [I've filed a
bug.|https://github.com/healthonnet/hon-lucene-synonyms/issues/5]

This is what I get for submitting my code to the harsh light of day! :)
Hopefully I can push out a fix by this weekend.

Also, thanks for the tip about sharedLib=lib. I'll test it out and add it to
the Getting Started instructions.

I agree that development should stay in GitHub for now. I'll re-request a merge
when the code is a bit more mature.

Query-time multi-word synonym expansion
---

Key: SOLR-4381
URL: https://issues.apache.org/jira/browse/SOLR-4381
Project: Solr
Issue Type: Improvement
Components: query parsers
Reporter: Nolan Lawson
Priority: Minor
Labels: multi-word, queryparser, synonyms
Fix For: 4.2, 5.0

Attachments: SOLR-4381-2.patch, SOLR-4381.patch

This is an issue that seems to come up perennially.
The [Solr
docs|http://wiki.apache.org/solr/AnalyzersTokenizersTokenFilters#solr.SynonymFilterFactory]
caution that index-time synonym expansion should be preferred to query-time
synonym expansion, due to the way multi-word synonyms are treated and how IDF
values can be boosted artificially. But query-time expansion should have huge
benefits, given that changes to the synonyms don't require re-indexing, the
index size stays the same, and the IDF values for the documents don't get
permanently altered.
The proposed solution is to move the synonym expansion logic from the
analysis chain (either query- or index-type) and into a new QueryParser. See
the attached patch for an implementation.
The core Lucene functionality is untouched. Instead, the EDismaxQParser is
extended, and synonym expansion is done on-the-fly. Queries are parsed into
a lattice (i.e. all possible synonym combinations), while individual
components of the query are still handled by the EDismaxQParser itself.
It's not an ideal solution by any stretch. But it's nice and self-contained,
so it invites experimentation and improvement. And I think it fits in well
with the merry band of misfit query parsers, like {{func}} and {{frange}}.
More details about this solution can be found in [this blog
post|http://nolanlawson.com/2012/10/31/better-synonym-handling-in-solr/] and
[the Github page for the
code|https://github.com/healthonnet/hon-lucene-synonyms].
At the risk of tooting my own horn, I also think this patch sufficiently
fixes SOLR-3390 (highlighting problems with multi-word synonyms) and
LUCENE-4499 (better support for multi-word synonyms).

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

[jira] [Commented] (SOLR-3141) Deprecate OPTIMIZE command in Solr


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

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

So, any thoughts on [~hossman]'s proposals above?

 Deprecate OPTIMIZE command in Solr
 --

 Key: SOLR-3141
 URL: https://issues.apache.org/jira/browse/SOLR-3141
 Project: Solr
  Issue Type: Improvement
  Components: update
Affects Versions: 3.5
Reporter: Jan Høydahl
  Labels: force, optimize
 Fix For: 4.2, 5.0

 Attachments: SOLR-3141.patch, SOLR-3141.patch


 Background: LUCENE-3454 renames optimize() as forceMerge(). Please read that 
 issue first.
 Now that optimize() is rarely necessary anymore, and renamed in Lucene APIs, 
 what should be done with Solr's ancient optimize command?

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4381) Query-time multi-word synonym expansion

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

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

Could you specify which private methods in eDisMax you needed to copy/paste?
Perhaps we can look at how to make it more extension friendly?

Query-time multi-word synonym expansion
---

Attachments: SOLR-4381-2.patch, SOLR-4381.patch

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

[jira] [Commented] (SOLR-4343) Solrcloud 4.1 inconsistent # of results in replicas

2013-01-31 Thread Joseph Dale (JIRA)

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

Joseph Dale commented on SOLR-4343:
---

I test up a test environment where I could give solr a larger amount of ram,
and this issue does not occur with the lower memory pressures. Regardless
solrcloud shoud be able to handle a few OOM's w/o lossing its mind.

-Joey

Solrcloud 4.1 inconsistent # of results in replicas

Key: SOLR-4343
URL: https://issues.apache.org/jira/browse/SOLR-4343
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.1
Environment: Ubuntu12.04 / Java 1.7.11 / Tomcat7 / Zookeeper 3.4.5
Reporter: Joseph Dale
Priority: Critical

I have a one shard collection, with one replica.
I did a dataImport from my oracle DB.
In the master, I have 93835 docs, in the non master 92627.
I have tried http://machinename:8080/solr/collection/update/commit=true on
the master, but the index does not replicate the replica.
Also, the node list different generations of the core.
I have left it alone for 2 hours and they never sync. Both nodes think that
they are current, only on really is. I can reproduce this 100% of the time.
-Joey

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

[jira] [Commented] (LUCENE-4736) Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be killed


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

Michael McCandless commented on LUCENE-4736:


Thanks Dawid, tests were successful after that commit!

I'll upgrade the JVM and re-test.

 Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be 
 killed
 

 Key: LUCENE-4736
 URL: https://issues.apache.org/jira/browse/LUCENE-4736
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Dawid Weiss

 EG:
 {noformat}
 ant test -Dtestcase=TestIndexWriterDelete -Dtests.seed=A22BC3E06CEC0036
 {noformat}
 Takes a while and then fails with this:
 {noformat}
 [junit4:junit4] ERROR   0.00s J2 | TestIndexWriterDelete (suite) 
 [junit4:junit4] Throwable #1:
 com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked
 from SUITE scope at org.apache.lucene.index.TestIndexWriterDelete:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 [junit4:junit4] Throwable #2:
 com.carrotsearch.randomizedtesting.ThreadLeakError: There are still
 zombie threads that couldn't be terminated:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 {noformat}
 Java version is:
 {noformat}
 java version 1.6.0
 Java(TM) SE Runtime Environment (build pxa6460sr9fp2ifix-2011_05(SR9 
 FP2+IV03622+IV02378+IZ99243+IZ97310+IV00707))
 IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
 jvmxa6460sr9-2011_94827 (JIT enabled, AOT enabled)
 J9VM - 2011_094827
 JIT  - r9_20101028_17488ifx45
 GC   - 20101027_AA)
 JCL  - 20110727_04
 {noformat}
 Curiously, I think it tends to happen on a test that fails an assumption?  Or 
 maybe I'm just imagining that ...

--
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-4735) IBM J9 JVM bug causes test failure in Kuromoji's TestExtended


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

Michael McCandless resolved LUCENE-4735.


Resolution: Fixed

OK, this was fixed in IBM's JVM, sometime between this version:
{noformat}
java version 1.6.0
Java(TM) SE Runtime Environment (build pxa6460sr9fp2ifix-2011_05(SR9 
FP2+IV03622+IV02378+IZ99243+IZ97310+IV00707))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
jvmxa6460sr9-2011_94827 (JIT enabled, AOT enabled)
J9VM - 2011_094827
JIT  - r9_20101028_17488ifx45
GC   - 20101027_AA)
JCL  - 20110727_04
{noformat}

and this one:

{noformat}
java version 1.6.0
Java(TM) SE Runtime Environment (build pxa6460sr12-20121025_01(SR12))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
jvmxa6460sr12-20121024_126067 (JIT enabled, AOT enabled)
J9VM - 20121024_126067
JIT  - r9_20120914_26057
GC   - 20120928_AA)
JCL  - 20121014_01
{noformat}


 IBM J9 JVM bug causes test failure in Kuromoji's TestExtended
 -

 Key: LUCENE-4735
 URL: https://issues.apache.org/jira/browse/LUCENE-4735
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
 Attachments: LUCENE-4735.patch, TestTreeMap2.java


 Note that this is not a Lucene bug; it's a JVM bug, but I wanted to track it 
 in Lucene as well in case others hit it.
 I noticed this test frequently fails when running under IBM's J9 JVM (1.6.0) 
 ... and I finally tracked down the root cause and made a small test case, eg 
 on trunk, rev 1439839, if you run:
 {noformat}
   ant test -Dtestcase=TestExtendedMode -Dtestmethod=testRandomHugeStrings 
 -Dtests.seed=26D2B352E9603950
 {noformat}
 it fails with this:
 {noformat}
 [junit4:junit4] Throwable #1: java.lang.IllegalArgumentException: 
 startOffset must be non-negative, and endOffset must be = startOffset, 
 startOffset=4272,endOffset=4271
 [junit4:junit4]  at 
 __randomizedtesting.SeedInfo.seed([26D2B352E9603950:BEF1D491B7168518]:0)
 [junit4:junit4]  at 
 org.apache.lucene.analysis.tokenattributes.OffsetAttributeImpl.setOffset(OffsetAttributeImpl.java:45)
 [junit4:junit4]  at 
 org.apache.lucene.analysis.ja.JapaneseTokenizer.incrementToken(JapaneseTokenizer.java:463)
 [junit4:junit4]  at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:635)
 [junit4:junit4]  at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:546)
 [junit4:junit4]  at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:447)
 [junit4:junit4]  at 
 org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:375)
 [junit4:junit4]  at 
 org.apache.lucene.analysis.ja.TestExtendedMode.testRandomHugeStrings(TestExtendedMode.java:76)
 {noformat}
 I've seen other analyzer tests fail with similar exceptions.
 I dug in, and found that there's a bug in TreeMap.subMap, and it's easily 
 reproduced with a small test case, which I'll attach.  I'll also open an 
 issue with J9.
 I also found a workaround that seems to sidestep the bug for Lucene.

--
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-4381) Query-time multi-word synonym expansion

2013-01-31 Thread Jack Krupansky (JIRA)

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

Jack Krupansky commented on SOLR-4381:
--

If this issue is to be seriously pursued as part of edismax, the following
should be included here in JIRA:

1. A concise summary of the overall approach, with key technical details.

2. A few example queries, both source and the resulting parsed query. Key
test cases, if you will.

3. A semi-detailed summary of what the user of the change needs to know, in
terms of how to set it up, manage it, use it, and its precise effects.

4. Detail any limitations.

That said, if you were to implement this as pat of a standalone, contrib
query parser, you you are much freer to do whatever you want with no regard to
potential consequences and need not worry about fine details. But if you want
this to be part of edismax, you'll need to be very, very careful. I would
suggest the former - it would allow you to get going much more rapidly.
Integration with edismax proper could be deferred until you're happy that
you've done all you've intended to do - and meanwhile the contrib module would
be available for others to use out of the box.

4. Specifically what features of the Synonym Filter will be lost by using this
approach.

Query-time multi-word synonym expansion
---

Attachments: SOLR-4381-2.patch, SOLR-4381.patch

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

[jira] [Updated] (LUCENE-4734) FastVectorHighlighter Overlapping Proximity Queries Do Not Highlight

2013-01-31 Thread Ryan Lauck (JIRA)


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

Ryan Lauck updated LUCENE-4734:
---

Fix Version/s: 5.0
   4.2
  Description: 
If a proximity phrase query overlaps with any other query term it will not be 
highlighted.

Example Text:  A B C D E F G

Example Queries: 

B E~10 D
(D will be highlighted instead of B C D E)

B E~10 C F~10
(nothing will be highlighted)


This can be traced to the FieldPhraseList constructor's inner while loop. From 
the first example query, the first TermInfo popped off the stack will be B. 
The second TermInfo will be D which will not be found in the submap for B 
E~10 and will trigger a failed match.

  was:
If a proximity phrase query overlaps with any other query term it will not be 
highlighted.

Example Text:  A B C D E F G

Example Queries: 

B E~10 D
(only D will be highlighted)

B E~10 C F~10
(neither phrase will be highlighted)


This can be traced to the FieldPhraseList constructor's inner while loop. From 
the first example query, the first TermInfo popped off the stack will be B. 
The second TermInfo will be D which will not be found in the submap for B 
E~10 and will trigger a failed match.

I wanted to report this issue before digging into a solution but my first 
thought is:

Add an additional int property to QueryPhraseMap to store the maximum possible 
phrase width for each term based on any proximity searches it is part of 
(defaulting to zero, in the above examples it would be 10). 

If a term is popped off the stack that is not a part of a proximity phrase 
being matched ( currMap.getTermMap(ti.getText()) == null ), it is added to a 
temporary list until either the longest possible phrase is successfully matched 
or a term is found outside the maximum possible phrase width.

After this search is complete, any non-matching terms that were added to the 
temporary list are pushed back onto the stack to be evaluated again and the 
temp list is cleared.

Hopefully this makes sense, and if nobody sees any obvious flaws I may try to 
create a patch.




Lucene Fields: New,Patch Available  (was: New)
Affects Version/s: 5.0

 FastVectorHighlighter Overlapping Proximity Queries Do Not Highlight
 

 Key: LUCENE-4734
 URL: https://issues.apache.org/jira/browse/LUCENE-4734
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/highlighter
Affects Versions: 4.0, 4.1, 5.0
Reporter: Ryan Lauck
  Labels: fastvectorhighlighter, highlighter
 Fix For: 4.2, 5.0

 Attachments: lucene-fvh-slop.patch


 If a proximity phrase query overlaps with any other query term it will not be 
 highlighted.
 Example Text:  A B C D E F G
 Example Queries: 
 B E~10 D
 (D will be highlighted instead of B C D E)
 B E~10 C F~10
 (nothing will be highlighted)
 This can be traced to the FieldPhraseList constructor's inner while loop. 
 From the first example query, the first TermInfo popped off the stack will be 
 B. The second TermInfo will be D which will not be found in the submap 
 for B E~10 and will trigger a failed match.

--
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: [jira] [Commented] (LUCENE-4736) Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be killed

2013-01-31 Thread Uwe Schindler

I will review and update Policeman Jenkins, too!

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


 -Original Message-
 From: Michael McCandless (JIRA) [mailto:j...@apache.org]
 Sent: Thursday, January 31, 2013 3:29 PM
 To: dev@lucene.apache.org
 Subject: [jira] [Commented] (LUCENE-4736) Some tests fail with IBM J9 due
 to strange TimerThread zombies that cannot be killed
 
 
 [ https://issues.apache.org/jira/browse/LUCENE-
 4736?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-
 tabpanelfocusedCommentId=13567666#comment-13567666 ]
 
 Michael McCandless commented on LUCENE-4736:
 
 
 Thanks Dawid, tests were successful after that commit!
 
 I'll upgrade the JVM and re-test.
 
  Some tests fail with IBM J9 due to strange TimerThread zombies that
  cannot be killed
  --
  --
 
  Key: LUCENE-4736
  URL: https://issues.apache.org/jira/browse/LUCENE-4736
  Project: Lucene - Core
   Issue Type: Bug
 Reporter: Michael McCandless
 Assignee: Dawid Weiss
 
  EG:
  {noformat}
  ant test -Dtestcase=TestIndexWriterDelete
  -Dtests.seed=A22BC3E06CEC0036 {noformat} Takes a while and then fails
  with this:
  {noformat}
  [junit4:junit4] ERROR   0.00s J2 | TestIndexWriterDelete (suite) 
  [junit4:junit4] Throwable #1:
  com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked
  from SUITE scope at org.apache.lucene.index.TestIndexWriterDelete:
  [junit4:junit4]1) Thread[id=102, name=Thread-44,
  state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
  [junit4:junit4] at java.lang.Object.wait(Native Method)
  [junit4:junit4] at java.lang.Object.wait(Object.java:196)
  [junit4:junit4] at 
  java.util.Timer$TimerImpl.run(Timer.java:247)
  [junit4:junit4]at
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
  [junit4:junit4] Throwable #2:
  com.carrotsearch.randomizedtesting.ThreadLeakError: There are still
  zombie threads that couldn't be terminated:
  [junit4:junit4]1) Thread[id=102, name=Thread-44,
  state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
  [junit4:junit4] at java.lang.Object.wait(Native Method)
  [junit4:junit4] at java.lang.Object.wait(Object.java:196)
  [junit4:junit4] at 
  java.util.Timer$TimerImpl.run(Timer.java:247)
  [junit4:junit4]at
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
  {noformat}
  Java version is:
  {noformat}
  java version 1.6.0
  Java(TM) SE Runtime Environment (build
  pxa6460sr9fp2ifix-2011_05(SR9
  FP2+IV03622+IV02378+IZ99243+IZ97310+IV00707))
  IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64
  jvmxa6460sr9-2011_94827 (JIT enabled, AOT enabled) J9VM -
  2011_094827 JIT  - r9_20101028_17488ifx45
  GC   - 20101027_AA)
  JCL  - 20110727_04
  {noformat}
  Curiously, I think it tends to happen on a test that fails an assumption?  
  Or
 maybe I'm just imagining that ...
 
 --
 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


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

Re: Please help building pylucene 3.6.2 on Solaris 11

2013-01-31 Thread Thomas Feuerstack


Am 30.01.2013 17:31, schrieb Andi Vajda:


Absolutely. If you want to contribute a patch with what you learned
getting pylucene and jcc to run on your combination of compiler and
operating system, by all means, send it in and I'll integrate it.


well, anyway and after all, i found there were only minimal changes to 
do in setup.py and Makefile to get a running pylucene, as described in 
the following. If you'll insert the necessary changes already in 
setup.py and Makefile, you'll only have to take care about to install 
the base-software and to run gmake instead of make.


--- snap ---
Installation notes for pylucene-3.6.2-1

JCC: Notes for Solaris
At this time, JCC has been built and tested only on Solaris 11.1 with 
gcc 4.5, Java 1.7 and Python 2.6. Make sure, you’ve already installed 
the following packages:


gcc-4.5
jre-1.7
jdk-1.7
python-2.6
ant
gnu-make
subversion

Missing packages can be installed vi “pkg install”.

1. Edit setup.py and do the following changes:

Inside JDK = { … }

change the entry for sunos5 to:

'sunos5': '/usr/jdk/instances/jdk1.7.0',

Inside CFLAGS= {…}

change the entry for sunos5 to:

'sunos5': ['-fno-strict-aliasing', '-Wno-write-strings'],

2. python setup.py build
3. su
   python setup.py install

pylucene: Notes for Solaris

PyLucene's Makefile is a GNU Makefile. Be sure to use gmake instead of 
plain make.


1. Edit Makefile and do the following changes:

Insert and enable a Solaris-Section with the following content

# Solaris   (Solaris 11.1, Python 2.6, 32-bit, Java 1.7)
PREFIX_PYTHON=/usr
ANT=/usr/bin/ant
PYTHON=$(PREFIX_PYTHON)/bin/python
JCC=$(PYTHON) -m jcc.__main__ --reserved DEFAULT_TYPE
NUM_FILES=4

2. gmake
3. su
   gmake install
---

please, send me a note, if something's still missing or not understandable.

:-) Thomas

[jira] [Reopened] (LUCENE-4739) FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes


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

Michael McCandless reopened LUCENE-4739:



Woops, not quite fixed ... there are FST ints that need to be fixed to long 
still ... I'm working on it.

 FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes
 

 Key: LUCENE-4739
 URL: https://issues.apache.org/jira/browse/LUCENE-4739
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Adrien Grand
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4739.patch


 This is really quite awful, but the test I created for  2.1 GB FSTs never 
 tested save/load ... and ... it doesn't work.

--
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-4392) DIH - Need to externalize or encrypt username/password stored within data-config.xml

2013-01-31 Thread Senthuran Sivananthan (JIRA)

Senthuran Sivananthan created SOLR-4392:
---

 Summary: DIH - Need to externalize or encrypt username/password 
stored within data-config.xml
 Key: SOLR-4392
 URL: https://issues.apache.org/jira/browse/SOLR-4392
 Project: Solr
  Issue Type: New Feature
  Components: contrib - DataImportHandler
Affects Versions: 4.1, 4.0
Reporter: Senthuran Sivananthan


Today, the connection (database or otherwise) credentials is wide open in 
data-config.xml.  Not really an issue until someone sends out the config file 
outside of the server.

We should look into externalizing the database lookup or providing a way to 
encrypt the username and password.

The needs are:

1/  Some projects want to enable multi-tenancy where data for each core is 
situated in different database servers w/ their own credentials.  We need a way 
to expose hooks that will allow implementations to be plugged in.  It can be 
done though the type attribute on the dataSource, but providing a factory 
might work better.

2/  Most orgs are very protective of their credentials and weary of plain-text 
settings.


--
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-4343) Solrcloud 4.1 inconsistent # of results in replicas

2013-01-31 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-4343:
---

Nah, thats a java thing, not a SolrCloud thing. I explained to you above how 
you have to deal with it.

 Solrcloud 4.1 inconsistent # of results in replicas 
 

 Key: SOLR-4343
 URL: https://issues.apache.org/jira/browse/SOLR-4343
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Ubuntu12.04 / Java 1.7.11 / Tomcat7 / Zookeeper 3.4.5
Reporter: Joseph Dale
Priority: Critical

 I have a one shard collection, with one replica.
 I did a dataImport from my oracle DB.
 In the master, I have 93835 docs, in the non master 92627.
 I have tried http://machinename:8080/solr/collection/update/commit=true on 
 the master, but the index does not replicate the replica.
 Also, the node list different generations of the core.
 I have left it alone for 2 hours and they never sync. Both nodes think that 
 they are current, only on really is. I can reproduce this 100% of the time.
 -Joey

--
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-4343) Solrcloud 4.1 inconsistent # of results in replicas

2013-01-31 Thread Mark Miller (JIRA)


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

Mark Miller resolved SOLR-4343.
---

Resolution: Not A Problem

 Solrcloud 4.1 inconsistent # of results in replicas 
 

 Key: SOLR-4343
 URL: https://issues.apache.org/jira/browse/SOLR-4343
 Project: Solr
  Issue Type: Bug
  Components: SolrCloud
Affects Versions: 4.1
 Environment: Ubuntu12.04 / Java 1.7.11 / Tomcat7 / Zookeeper 3.4.5
Reporter: Joseph Dale
Priority: Critical

 I have a one shard collection, with one replica.
 I did a dataImport from my oracle DB.
 In the master, I have 93835 docs, in the non master 92627.
 I have tried http://machinename:8080/solr/collection/update/commit=true on 
 the master, but the index does not replicate the replica.
 Also, the node list different generations of the core.
 I have left it alone for 2 hours and they never sync. Both nodes think that 
 they are current, only on really is. I can reproduce this 100% of the time.
 -Joey

--
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-4736) Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be killed


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

Michael McCandless commented on LUCENE-4736:


All tests passed after I upgraded the JVM to:

{noformat}
Java(TM) SE Runtime Environment (build pxa6460sr12-20121025_01(SR12))
IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
jvmxa6460sr12-20121024_126067 (JIT enabled, AOT enabled)
J9VM - 20121024_126067
JIT  - r9_20120914_26057
GC   - 20120928_AA)
JCL  - 20121014_01
{noformat}

Thanks Dawid!


 Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be 
 killed
 

 Key: LUCENE-4736
 URL: https://issues.apache.org/jira/browse/LUCENE-4736
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Dawid Weiss

 EG:
 {noformat}
 ant test -Dtestcase=TestIndexWriterDelete -Dtests.seed=A22BC3E06CEC0036
 {noformat}
 Takes a while and then fails with this:
 {noformat}
 [junit4:junit4] ERROR   0.00s J2 | TestIndexWriterDelete (suite) 
 [junit4:junit4] Throwable #1:
 com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked
 from SUITE scope at org.apache.lucene.index.TestIndexWriterDelete:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 [junit4:junit4] Throwable #2:
 com.carrotsearch.randomizedtesting.ThreadLeakError: There are still
 zombie threads that couldn't be terminated:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 {noformat}
 Java version is:
 {noformat}
 java version 1.6.0
 Java(TM) SE Runtime Environment (build pxa6460sr9fp2ifix-2011_05(SR9 
 FP2+IV03622+IV02378+IZ99243+IZ97310+IV00707))
 IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
 jvmxa6460sr9-2011_94827 (JIT enabled, AOT enabled)
 J9VM - 2011_094827
 JIT  - r9_20101028_17488ifx45
 GC   - 20101027_AA)
 JCL  - 20110727_04
 {noformat}
 Curiously, I think it tends to happen on a test that fails an assumption?  Or 
 maybe I'm just imagining that ...

--
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-4740) Weak references cause extreme GC churn

Kristofer Karlsson created LUCENE-4740:
--

 Summary: Weak references cause extreme GC churn
 Key: LUCENE-4740
 URL: https://issues.apache.org/jira/browse/LUCENE-4740
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.6.1
 Environment: Linux debian squeeze 64 bit, Oracle JDK 6, 32 GB RAM, 16 
cores
Reporter: Kristofer Karlsson
Priority: Critical


We are running a set of independent search machines, running our custom 
software using lucene as a search library. We recently upgraded from lucene 
3.0.3 to 3.6.1 and noticed a severe degradation of performance.

After doing some heap dump digging, it turns out the process is stalling 
because it's spending so much time in GC. We noticed about 212 million 
WeakReference, originating from WeakIdentityMap, originating from 
MMapIndexInput.

Our problem completely went away after removing the clones weakhashmap from 
MMapIndexInput, and as a side-effect, disabling support for explictly unmapping 
the mmapped data.


--
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-4740) Weak references cause extreme GC churn


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

Kristofer Karlsson commented on LUCENE-4740:


I am not sure if this is a problem in practice, but there are also 
WeakIdentityMaps used in AttributeImpl, AttributeSource, VirtualMethod where 
the keys of the map are classes, which I don't imagine get allocated or 
collected a lot at all.

I replaced those maps with regular ConcurrentHashMapClass, X without any 
negative impact.

 Weak references cause extreme GC churn
 --

 Key: LUCENE-4740
 URL: https://issues.apache.org/jira/browse/LUCENE-4740
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 3.6.1
 Environment: Linux debian squeeze 64 bit, Oracle JDK 6, 32 GB RAM, 16 
 cores
Reporter: Kristofer Karlsson
Priority: Critical

 We are running a set of independent search machines, running our custom 
 software using lucene as a search library. We recently upgraded from lucene 
 3.0.3 to 3.6.1 and noticed a severe degradation of performance.
 After doing some heap dump digging, it turns out the process is stalling 
 because it's spending so much time in GC. We noticed about 212 million 
 WeakReference, originating from WeakIdentityMap, originating from 
 MMapIndexInput.
 Our problem completely went away after removing the clones weakhashmap from 
 MMapIndexInput, and as a side-effect, disabling support for explictly 
 unmapping the mmapped data.

--
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-4740) Weak references cause extreme GC churn


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

Kristofer Karlsson updated LUCENE-4740:
---

Component/s: (was: core/index)
 core/store

 Weak references cause extreme GC churn
 --

 Key: LUCENE-4740
 URL: https://issues.apache.org/jira/browse/LUCENE-4740
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/store
Affects Versions: 3.6.1
 Environment: Linux debian squeeze 64 bit, Oracle JDK 6, 32 GB RAM, 16 
 cores
Reporter: Kristofer Karlsson
Priority: Critical

 We are running a set of independent search machines, running our custom 
 software using lucene as a search library. We recently upgraded from lucene 
 3.0.3 to 3.6.1 and noticed a severe degradation of performance.
 After doing some heap dump digging, it turns out the process is stalling 
 because it's spending so much time in GC. We noticed about 212 million 
 WeakReference, originating from WeakIdentityMap, originating from 
 MMapIndexInput.
 Our problem completely went away after removing the clones weakhashmap from 
 MMapIndexInput, and as a side-effect, disabling support for explictly 
 unmapping the mmapped data.

--
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-4740) Weak references cause extreme GC churn


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

Kristofer Karlsson commented on LUCENE-4740:


This seems to be somewhat addressed in trunk, with the inputs in 
http://svn.apache.org/repos/asf/lucene/dev/trunk/lucene/core/src/java/org/apache/lucene/store/ByteBufferIndexInput.java
 removing themselves from the clones list on close(). Should that be backported 
to 3.x?

 Weak references cause extreme GC churn
 --

 Key: LUCENE-4740
 URL: https://issues.apache.org/jira/browse/LUCENE-4740
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/store
Affects Versions: 3.6.1
 Environment: Linux debian squeeze 64 bit, Oracle JDK 6, 32 GB RAM, 16 
 cores
Reporter: Kristofer Karlsson
Priority: Critical

 We are running a set of independent search machines, running our custom 
 software using lucene as a search library. We recently upgraded from lucene 
 3.0.3 to 3.6.1 and noticed a severe degradation of performance.
 After doing some heap dump digging, it turns out the process is stalling 
 because it's spending so much time in GC. We noticed about 212 million 
 WeakReference, originating from WeakIdentityMap, originating from 
 MMapIndexInput.
 Our problem completely went away after removing the clones weakhashmap from 
 MMapIndexInput, and as a side-effect, disabling support for explictly 
 unmapping the mmapped data.

--
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-4740) Weak references cause extreme GC churn

2013-01-31 Thread Uwe Schindler (JIRA)

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

Uwe Schindler commented on LUCENE-4740:
---

bq. I replaced those maps with regular ConcurrentHashMapClass, X without any
negative impact.

This kills the possibility of unloading web applications in application
servers. Those maps don't produce many references.

Which OS are you using? Somebody had a similar problem on Windows.

Weak references cause extreme GC churn
--

Key: LUCENE-4740
URL: https://issues.apache.org/jira/browse/LUCENE-4740
Project: Lucene - Core
Issue Type: Bug
Components: core/store
Affects Versions: 3.6.1
Environment: Linux debian squeeze 64 bit, Oracle JDK 6, 32 GB RAM, 16
cores
Reporter: Kristofer Karlsson
Priority: Critical

We are running a set of independent search machines, running our custom
software using lucene as a search library. We recently upgraded from lucene
3.0.3 to 3.6.1 and noticed a severe degradation of performance.
After doing some heap dump digging, it turns out the process is stalling
because it's spending so much time in GC. We noticed about 212 million
WeakReference, originating from WeakIdentityMap, originating from
MMapIndexInput.
Our problem completely went away after removing the clones weakhashmap from
MMapIndexInput, and as a side-effect, disabling support for explictly
unmapping the mmapped data.

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

[jira] [Comment Edited] (LUCENE-4740) Weak references cause extreme GC churn

2013-01-31 Thread Uwe Schindler (JIRA)

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

Uwe Schindler edited comment on LUCENE-4740 at 1/31/13 4:28 PM:

bq. I replaced those maps with regular ConcurrentHashMapClass, X without any
negative impact.

This kills the possibility of unloading web applications in application
servers. Those maps don't produce many references.

Which OS are you using? Somebody had a similar problem on Windows - but on
Linux all was fine. Maybe some JVM version has a bug in reference queues... Can
you give your exact version number?

was (Author: thetaphi):
bq. I replaced those maps with regular ConcurrentHashMapClass, X without
any negative impact.

This kills the possibility of unloading web applications in application
servers. Those maps don't produce many references.

Which OS are you using? Somebody had a similar problem on Windows.

Weak references cause extreme GC churn
--

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

[jira] [Updated] (LUCENE-4734) FastVectorHighlighter Overlapping Proximity Queries Do Not Highlight

2013-01-31 Thread Ryan Lauck (JIRA)


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

Ryan Lauck updated LUCENE-4734:
---

Attachment: lucene-fvh-slop-reverse.patch

I hope I'm not stepping on any toes here, but I realized my patch is similar to 
some of the work done in LUCENE-4118. My patch also solves the bug where 
repeated terms in a proximity query cause highlight matching to fail.

I also took a different approach to handling reverse order matching on slop 
queries so that this patch could be a complete alternative to LUCENE-4118. I 
modified QueryPhraseMap.add to detect PhraseQuerys with slop and create a 
second mapping for the phrase terms in reverse order - this way no other code 
needs to change to handle proximity phrase terms appearing in reverse order.

I added two simple test cases for both reverse ordering and repeated terms.

 FastVectorHighlighter Overlapping Proximity Queries Do Not Highlight
 

 Key: LUCENE-4734
 URL: https://issues.apache.org/jira/browse/LUCENE-4734
 Project: Lucene - Core
  Issue Type: Bug
  Components: modules/highlighter
Affects Versions: 4.0, 4.1, 5.0
Reporter: Ryan Lauck
  Labels: fastvectorhighlighter, highlighter
 Fix For: 4.2, 5.0

 Attachments: lucene-fvh-slop.patch, lucene-fvh-slop-reverse.patch


 If a proximity phrase query overlaps with any other query term it will not be 
 highlighted.
 Example Text:  A B C D E F G
 Example Queries: 
 B E~10 D
 (D will be highlighted instead of B C D E)
 B E~10 C F~10
 (nothing will be highlighted)
 This can be traced to the FieldPhraseList constructor's inner while loop. 
 From the first example query, the first TermInfo popped off the stack will be 
 B. The second TermInfo will be D which will not be found in the submap 
 for B E~10 and will trigger a failed match.

--
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-4740) Weak references cause extreme GC churn


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

Kristofer Karlsson commented on LUCENE-4740:


Yes, that change is probably not a good general solution, but it worked well 
for our usecase. It might be nice to have support for unloadable classes 
optional.

I am using debian squeeze, 64 bit, Oracle JDK 6 with a 16 GB heap and four 
indexes, totalling 9 GB
{noformat}
java version 1.6.0_26
Java(TM) SE Runtime Environment (build 1.6.0_26-b03)
Java HotSpot(TM) 64-Bit Server VM (build 20.1-b02, mixed mode)
{noformat}

The 212M WeakReferences on the heap indicates that the referencequeues weren't 
functioning correctly.

In any case, if the useUnmap is false, then it seems unnecessary to even add 
references to the clones to the map.

 Weak references cause extreme GC churn
 --

 Key: LUCENE-4740
 URL: https://issues.apache.org/jira/browse/LUCENE-4740
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/store
Affects Versions: 3.6.1
 Environment: Linux debian squeeze 64 bit, Oracle JDK 6, 32 GB RAM, 16 
 cores
Reporter: Kristofer Karlsson
Priority: Critical

 We are running a set of independent search machines, running our custom 
 software using lucene as a search library. We recently upgraded from lucene 
 3.0.3 to 3.6.1 and noticed a severe degradation of performance.
 After doing some heap dump digging, it turns out the process is stalling 
 because it's spending so much time in GC. We noticed about 212 million 
 WeakReference, originating from WeakIdentityMap, originating from 
 MMapIndexInput.
 Our problem completely went away after removing the clones weakhashmap from 
 MMapIndexInput, and as a side-effect, disabling support for explictly 
 unmapping the mmapped data.

--
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-4740) Weak references cause extreme GC churn

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

Robert Muir commented on LUCENE-4740:
-

{quote}
In any case, if the useUnmap is false, then it seems unnecessary to even add
references to the clones to the map.
{quote}

+1, I think make it null in this case. it just gives the user options (with
different tradeoffs).

Weak references cause extreme GC churn
--

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

[jira] [Comment Edited] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module


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

Kai Gülzau edited comment on LUCENE-2899 at 1/31/13 7:11 PM:
-

End of OpenNLPTokenizer.fillBuffer() should be:
{code}
while(length == size) {
  offset += size;
  fullText = Arrays.copyOf(fullText, offset + size);
  length = input.read(fullText, offset, size);
}
if (length == -1) {
  length = 0;
}
fullText = Arrays.copyOf(fullText, offset + length);
{code}

  was (Author: kguel...@novomind.com):
End of OpenNLPTokenizer.fillBuffer() should be:
{code}
if (length  0) {
  fullText = Arrays.copyOf(fullText, offset + length);
}
{code}
  
 Add OpenNLP Analysis capabilities as a module
 -

 Key: LUCENE-2899
 URL: https://issues.apache.org/jira/browse/LUCENE-2899
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
 LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, OpenNLPFilter.java, 
 OpenNLPTokenizer.java, opennlp_trunk.patch


 Now that OpenNLP is an ASF project and has a nice license, it would be nice 
 to have a submodule (under analysis) that exposed capabilities for it. Drew 
 Farris, Tom Morton and I have code that does:
 * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
 would have to change slightly to buffer tokens)
 * NamedEntity recognition as a TokenFilter
 We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
 either payloads (PartOfSpeechAttribute?) on a token or at the same position.
 I'd propose it go under:
 modules/analysis/opennlp

--
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-381) delete-by-query does not support purely negative queries


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

Commit Tag Bot commented on SOLR-381:
-

[trunk commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revisionrevision=1441154

SOLR-381: test demonstrating deleteByQuery works with pure-negative queries, 
and QParsers in general


 delete-by-query does not support purely negative queries
 

 Key: SOLR-381
 URL: https://issues.apache.org/jira/browse/SOLR-381
 Project: Solr
  Issue Type: Bug
  Components: update
Reporter: Erik Hatcher
Priority: Minor

 Reported by Rob Casson:
 {noformat}
 indexing the example docs from 1.2, these steps work:
 curl http://localhost:8983/solr/update --data-binary
 'deletequerysolr/query/delete' -H 'Content-type:text/xml;
 charset=utf-8'
 curl http://localhost:8983/solr/update --data-binary 'optimize /' -H
 'Content-type:text/xml; charset=utf-8'
 but if i reindex, and change the delete query to a negative, the
 non-'solr' docs don't get deleted:
 curl http://localhost:8983/solr/update --data-binary
 'deletequery-solr/query/delete' -H 'Content-type:text/xml;
 charset=utf-8'
 curl http://localhost:8983/solr/update --data-binary 'optimize /' -H
 'Content-type:text/xml; charset=utf-8'
 And detailed by Hoss with a workaround:
 the delete by query does the 
 right thing with a purely negative query ... when the customization was 
 added to Solr to support pure negative queries it was done at the 
 SolrIndexSearcher level when computing DocSets, but delete by query uses a 
 lower level method passing in a HitCOllector.
 the work arround is to include *:* in yoru query ...
deletequery*:* -solr/query/delete
 ... if/when this is fixed 
 in Solr that's esentally what solr will do under the covers.
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-381) delete-by-query does not support purely negative queries

2013-01-31 Thread Hoss Man (JIRA)


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

Hoss Man resolved SOLR-381.
---

   Resolution: Fixed
Fix Version/s: 4.0

This appears to have been fixed in 4.0, i've added a test to verify no 
regressions moving forward...

Committed revision 1441154.
Committed revision 1441155.



 delete-by-query does not support purely negative queries
 

 Key: SOLR-381
 URL: https://issues.apache.org/jira/browse/SOLR-381
 Project: Solr
  Issue Type: Bug
  Components: update
Reporter: Erik Hatcher
Priority: Minor
 Fix For: 4.0


 Reported by Rob Casson:
 {noformat}
 indexing the example docs from 1.2, these steps work:
 curl http://localhost:8983/solr/update --data-binary
 'deletequerysolr/query/delete' -H 'Content-type:text/xml;
 charset=utf-8'
 curl http://localhost:8983/solr/update --data-binary 'optimize /' -H
 'Content-type:text/xml; charset=utf-8'
 but if i reindex, and change the delete query to a negative, the
 non-'solr' docs don't get deleted:
 curl http://localhost:8983/solr/update --data-binary
 'deletequery-solr/query/delete' -H 'Content-type:text/xml;
 charset=utf-8'
 curl http://localhost:8983/solr/update --data-binary 'optimize /' -H
 'Content-type:text/xml; charset=utf-8'
 And detailed by Hoss with a workaround:
 the delete by query does the 
 right thing with a purely negative query ... when the customization was 
 added to Solr to support pure negative queries it was done at the 
 SolrIndexSearcher level when computing DocSets, but delete by query uses a 
 lower level method passing in a HitCOllector.
 the work arround is to include *:* in yoru query ...
deletequery*:* -solr/query/delete
 ... if/when this is fixed 
 in Solr that's esentally what solr will do under the covers.
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4740) Weak references cause extreme GC churn


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

Kristofer Karlsson commented on LUCENE-4740:


Agree that the weakreferences for classes is probably a very minor part of it, 
and very unlikely part of the problem here.

The unmap option is nice, and you could make it less complicated by simply 
disallowing the option to be changed after the mmapdirectory has ever been 
cloned. In practice it will always be set immediately after construction.

 Weak references cause extreme GC churn
 --

 Key: LUCENE-4740
 URL: https://issues.apache.org/jira/browse/LUCENE-4740
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/store
Affects Versions: 3.6.1
 Environment: Linux debian squeeze 64 bit, Oracle JDK 6, 32 GB RAM, 16 
 cores
Reporter: Kristofer Karlsson
Priority: Critical

 We are running a set of independent search machines, running our custom 
 software using lucene as a search library. We recently upgraded from lucene 
 3.0.3 to 3.6.1 and noticed a severe degradation of performance.
 After doing some heap dump digging, it turns out the process is stalling 
 because it's spending so much time in GC. We noticed about 212 million 
 WeakReference, originating from WeakIdentityMap, originating from 
 MMapIndexInput.
 Our problem completely went away after removing the clones weakhashmap from 
 MMapIndexInput, and as a side-effect, disabling support for explictly 
 unmapping the mmapped data.

--
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-381) delete-by-query does not support purely negative queries


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

Commit Tag Bot commented on SOLR-381:
-

[branch_4x commit] Chris M. Hostetter
http://svn.apache.org/viewvc?view=revisionrevision=1441155

SOLR-381: test demonstrating deleteByQuery works with pure-negative queries, 
and QParsers in general (merge r1441154)


 delete-by-query does not support purely negative queries
 

 Key: SOLR-381
 URL: https://issues.apache.org/jira/browse/SOLR-381
 Project: Solr
  Issue Type: Bug
  Components: update
Reporter: Erik Hatcher
Priority: Minor
 Fix For: 4.0


 Reported by Rob Casson:
 {noformat}
 indexing the example docs from 1.2, these steps work:
 curl http://localhost:8983/solr/update --data-binary
 'deletequerysolr/query/delete' -H 'Content-type:text/xml;
 charset=utf-8'
 curl http://localhost:8983/solr/update --data-binary 'optimize /' -H
 'Content-type:text/xml; charset=utf-8'
 but if i reindex, and change the delete query to a negative, the
 non-'solr' docs don't get deleted:
 curl http://localhost:8983/solr/update --data-binary
 'deletequery-solr/query/delete' -H 'Content-type:text/xml;
 charset=utf-8'
 curl http://localhost:8983/solr/update --data-binary 'optimize /' -H
 'Content-type:text/xml; charset=utf-8'
 And detailed by Hoss with a workaround:
 the delete by query does the 
 right thing with a purely negative query ... when the customization was 
 added to Solr to support pure negative queries it was done at the 
 SolrIndexSearcher level when computing DocSets, but delete by query uses a 
 lower level method passing in a HitCOllector.
 the work arround is to include *:* in yoru query ...
deletequery*:* -solr/query/delete
 ... if/when this is fixed 
 in Solr that's esentally what solr will do under the covers.
 {noformat}

--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-MacOSX (64bit/jdk1.7.0) - Build # 152 - Failure!

2013-01-31 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/152/
Java: 64bit/jdk1.7.0 -XX:+UseG1GC

All tests passed

Build Log:
[...truncated 8920 lines...]
[junit4:junit4] ERROR: JVM J0 ended with an exception, command line: 
/Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/bin/java 
-XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/heapdumps
 -Dtests.prefix=tests -Dtests.seed=F296F9429FD6A5D6 -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.locale=random -Dtests.timezone=random 
-Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz 
-Dtests.luceneMatchVersion=4.2 -Dtests.cleanthreads=perClass 
-Djava.util.logging.config.file=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/testlogging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
-Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. 
-Djava.io.tmpdir=. 
-Djunit4.tempDir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/temp
 
-Dclover.db.dir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/clover/db
 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Djava.security.policy=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/tests.policy
 -Dlucene.version=4.2-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Dfile.encoding=ISO-8859-1 -classpath

[jira] [Commented] (SOLR-4377) making release tarballs identical to the release tags

2013-01-31 Thread Mark Miller (JIRA)


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

Mark Miller commented on SOLR-4377:
---

Other differences I missed:

NOTICE and README end up in root but are not there in svn, clover folder is 
excluded in dist (has license file)

Also expected.

 making release tarballs identical to the release tags
 -

 Key: SOLR-4377
 URL: https://issues.apache.org/jira/browse/SOLR-4377
 Project: Solr
  Issue Type: Improvement
  Components: scripts and tools
Affects Versions: 4.0, 4.1
Reporter: Roman Shaposhnik
 Fix For: 4.2, 5.0

 Attachments: diff.txt


 Now that we're integrating Solr with Hadoop via the Apache Bigtop project it 
 is a bit of a nuisance to our build system that the release tarballs don't 
 quite match the SVN tags. This is also something that is not quite ASF kosher 
 strictly speaking. 
 Would it be ok with a Solr community to add a comparison check between 
 release tarballs and SVN tags as part of the release process checklist?
 If you guys have a Wiki outlining how-to-release perhaps it needs to be 
 captured over there or just added to the process. Either way would be fine.

--
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-4739) FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes


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

Michael McCandless updated LUCENE-4739:
---

Attachment: LUCENE-4739.patch

Patch, I think it's ready.

Test2BFST passed ... (took 4 hours).

 FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes
 

 Key: LUCENE-4739
 URL: https://issues.apache.org/jira/browse/LUCENE-4739
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Adrien Grand
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4739.patch, LUCENE-4739.patch


 This is really quite awful, but the test I created for  2.1 GB FSTs never 
 tested save/load ... and ... it doesn't work.

--
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-4740) Weak references cause extreme GC churn


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

Kristofer Karlsson commented on LUCENE-4740:


After doing some more thinking and micro-benchmarking, I think the problem 
occurs when you create clones at a faster rate than the GC can cope with.
{noformat}
public class WeakTest extends TestCase {
private static final int CPUS = Runtime.getRuntime().availableProcessors();

public void testFoo() throws Exception {
final WeakIdentityMapObject, Boolean map = 
WeakIdentityMap.newConcurrentHashMap();
ExecutorService executorService = Executors.newCachedThreadPool();

for (int k = 0; k  CPUS; k++) {
executorService.submit(new Runnable() {
public void run() {
while (true) {
map.put(new Object(), Boolean.TRUE);
}
}
});
executorService.submit(new Runnable() {
public void run() {
while (true) {
System.gc();
}
}
});
}
while (true) {
System.out.println(Map size:  + map.size());
Thread.sleep(1000);
}
}

}
{noformat}
I tried running this with -Xmx100m. This makes the map grow indefinitely.
I know this is not a very reliable test, since the JVM only considers 
System.gc() a hint, but it definitely seems like it's not very good at freeing 
weak references during high load.

If I add Thread.sleep(1) in the put-worker, I can make it grow slower, but it 
still seems to grow over time.

(Running java 7 on my home computer)
{noformat}
java version 1.7.0_07
Java(TM) SE Runtime Environment (build 1.7.0_07-b10)
Java HotSpot(TM) 64-Bit Server VM (build 23.3-b01, mixed mode)
{noformat}


 Weak references cause extreme GC churn
 --

 Key: LUCENE-4740
 URL: https://issues.apache.org/jira/browse/LUCENE-4740
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/store
Affects Versions: 3.6.1
 Environment: Linux debian squeeze 64 bit, Oracle JDK 6, 32 GB RAM, 16 
 cores
Reporter: Kristofer Karlsson
Priority: Critical

 We are running a set of independent search machines, running our custom 
 software using lucene as a search library. We recently upgraded from lucene 
 3.0.3 to 3.6.1 and noticed a severe degradation of performance.
 After doing some heap dump digging, it turns out the process is stalling 
 because it's spending so much time in GC. We noticed about 212 million 
 WeakReference, originating from WeakIdentityMap, originating from 
 MMapIndexInput.
 Our problem completely went away after removing the clones weakhashmap from 
 MMapIndexInput, and as a side-effect, disabling support for explictly 
 unmapping the mmapped data.

--
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-4742) Rename SpatialPrefixTree's Node back to Cell

2013-01-31 Thread David Smiley (JIRA)

David Smiley created LUCENE-4742:


 Summary: Rename SpatialPrefixTree's Node back to Cell
 Key: LUCENE-4742
 URL: https://issues.apache.org/jira/browse/LUCENE-4742
 Project: Lucene - Core
  Issue Type: Improvement
  Components: modules/spatial
Reporter: David Smiley
Priority: Trivial


SpatialPrefixTree makes Nodes which are basically a rectangular spatial 
region that is more colloquially referred to as a Cell.  It was named Cell 
in the first place and for whatever reason, Ryan and/or Chris renamed it as 
part of extracting it to a top level class from an inner class.  Most comments 
and variable names still use the cell terminology.  I'm working on an 
algorithm that keeps track of a tree of nodes and it has gotten confusing 
which kind of node I'm referring to, as each Node has one cell.

In maybe a week or so if there isn't discussion to the contrary, I'm going to 
commit a rename it back to Cell.  And... while we're on this naming subject, 
perhaps SpatialPrefixTree could be named SpatialGrid ?  FWIW the variables 
referring to it are always grid.

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

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

[jira] [Assigned] (LUCENE-4742) Rename SpatialPrefixTree's Node back to Cell

2013-01-31 Thread David Smiley (JIRA)

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

David Smiley reassigned LUCENE-4742:

Assignee: David Smiley

Rename SpatialPrefixTree's Node back to Cell

Key: LUCENE-4742
URL: https://issues.apache.org/jira/browse/LUCENE-4742
Project: Lucene - Core
Issue Type: Improvement
Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Priority: Trivial

SpatialPrefixTree makes Nodes which are basically a rectangular spatial
region that is more colloquially referred to as a Cell. It was named
Cell in the first place and for whatever reason, Ryan and/or Chris renamed
it as part of extracting it to a top level class from an inner class. Most
comments and variable names still use the cell terminology. I'm working on
an algorithm that keeps track of a tree of nodes and it has gotten
confusing which kind of node I'm referring to, as each Node has one cell.
In maybe a week or so if there isn't discussion to the contrary, I'm going to
commit a rename it back to Cell. And... while we're on this naming
subject, perhaps SpatialPrefixTree could be named SpatialGrid ? FWIW the
variables referring to it are always grid.

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

[jira] [Updated] (LUCENE-4682) Reduce wasted bytes in FST due to array arcs

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

Michael McCandless updated LUCENE-4682:
---

Attachment: fstByteStats.txt

I was curious about the number of times each byte value occurs in an FST ...
because we could pick an uncommon one and use it as periodic marker (eg ever 5
arcs or something) to enable binary searching.

So I ran this on two FSTs ... first one is all Wikipedia terms and second one
is FreeDB suggester (has some non-ascii song titles...).

Not sure exactly what to conclude since a byte's frequency is FST dependent ...

Reduce wasted bytes in FST due to array arcs

Key: LUCENE-4682
URL: https://issues.apache.org/jira/browse/LUCENE-4682
Project: Lucene - Core
Issue Type: Improvement
Components: core/FSTs
Reporter: Michael McCandless
Priority: Minor
Attachments: fstByteStats.txt, kuromoji.wasted.bytes.txt,
LUCENE-4682.patch

When a node is close to the root, or it has many outgoing arcs, the FST
writes the arcs as an array (each arc gets N bytes), so we can e.g. bin
search on lookup.
The problem is N is set to the max(numBytesPerArc), so if you have an outlier
arc e.g. with a big output, you can waste many bytes for all the other arcs
that didn't need so many bytes.
I generated Kuromoji's FST and found it has 271187 wasted bytes vs total size
1535612 = ~18% wasted.
It would be nice to reduce this.
One thing we could do without packing is: in addNode, if we detect that
number of wasted bytes is above some threshold, then don't do the expansion.
Another thing, if we are packing: we could record stats in the first pass
about which nodes wasted the most, and then in the second pass (paack) we
could set the threshold based on the top X% nodes that waste ...
Another idea is maybe to deref large outputs, so that the numBytesPerArc is
more uniform ...

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

[jira] [Commented] (LUCENE-4682) Reduce wasted bytes in FST due to array arcs

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

Robert Muir commented on LUCENE-4682:
-

{quote}
Not sure exactly what to conclude since a byte's frequency is FST dependent ...
{quote}

So we can just add it as another param to the massive FST.Builder ctor!

Reduce wasted bytes in FST due to array arcs

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

[jira] [Commented] (LUCENE-4733) Make CompressingTermVectorsFormat the new default term vectors format?


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

Robert Muir commented on LUCENE-4733:
-

+1: though I think we need a little javadoc sentence on that since its in 
test-framework or the build will complain.

we can just describe its ideal purpose is to be the one test for your format 
like the postings/docvalues equivalents.


 Make CompressingTermVectorsFormat the new default term vectors format?
 --

 Key: LUCENE-4733
 URL: https://issues.apache.org/jira/browse/LUCENE-4733
 Project: Lucene - Core
  Issue Type: Improvement
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Trivial
 Fix For: 4.2

 Attachments: LUCENE-4733-tests.patch


 In LUCENE-4599, I wrote an alternate term vectors format which has a more 
 compact format, and I think it could replace the current 
 Lucene40TermVectorsFormat for the next (4.2) release?

--
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-2899) Add OpenNLP Analysis capabilities as a module

2013-01-31 Thread Lance Norskog (JIRA)


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

Lance Norskog commented on LUCENE-2899:
---

Thank you. Have you tried this on the trunk? The Solr components did not work, 
they could not find the OpenNLP jars.


 Add OpenNLP Analysis capabilities as a module
 -

 Key: LUCENE-2899
 URL: https://issues.apache.org/jira/browse/LUCENE-2899
 Project: Lucene - Core
  Issue Type: New Feature
  Components: modules/analysis
Reporter: Grant Ingersoll
Assignee: Grant Ingersoll
Priority: Minor
 Fix For: 4.2, 5.0

 Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, 
 LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch, OpenNLPFilter.java, 
 OpenNLPTokenizer.java, opennlp_trunk.patch


 Now that OpenNLP is an ASF project and has a nice license, it would be nice 
 to have a submodule (under analysis) that exposed capabilities for it. Drew 
 Farris, Tom Morton and I have code that does:
 * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it 
 would have to change slightly to buffer tokens)
 * NamedEntity recognition as a TokenFilter
 We are also planning a Tokenizer/TokenFilter that can put parts of speech as 
 either payloads (PartOfSpeechAttribute?) on a token or at the same position.
 I'd propose it go under:
 modules/analysis/opennlp

--
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-4739) FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes


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

Michael McCandless resolved LUCENE-4739.


Resolution: Fixed

 FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes
 

 Key: LUCENE-4739
 URL: https://issues.apache.org/jira/browse/LUCENE-4739
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Adrien Grand
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4739.patch, LUCENE-4739.patch


 This is really quite awful, but the test I created for  2.1 GB FSTs never 
 tested save/load ... and ... it doesn't work.

--
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-4739) FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes


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

Commit Tag Bot commented on LUCENE-4739:


[trunk commit] Michael McCandless
http://svn.apache.org/viewvc?view=revisionrevision=1441213

LUCENE-4739: fix FST.save/load to work with  1.1 GB FSTs


 FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes
 

 Key: LUCENE-4739
 URL: https://issues.apache.org/jira/browse/LUCENE-4739
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Adrien Grand
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4739.patch, LUCENE-4739.patch


 This is really quite awful, but the test I created for  2.1 GB FSTs never 
 tested save/load ... and ... it doesn't work.

--
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-4739) FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes


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

Robert Muir commented on LUCENE-4739:
-

Thanks guys!

 FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes
 

 Key: LUCENE-4739
 URL: https://issues.apache.org/jira/browse/LUCENE-4739
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Adrien Grand
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4739.patch, LUCENE-4739.patch


 This is really quite awful, but the test I created for  2.1 GB FSTs never 
 tested save/load ... and ... it doesn't work.

--
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-4739) FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes


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

Commit Tag Bot commented on LUCENE-4739:


[branch_4x commit] Michael McCandless
http://svn.apache.org/viewvc?view=revisionrevision=1441214

LUCENE-4739: fix FST.save/load to work with  1.1 GB FSTs


 FST cannot be loaded if it's larger than Integer.MAX_VALUE / 2 bytes
 

 Key: LUCENE-4739
 URL: https://issues.apache.org/jira/browse/LUCENE-4739
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Adrien Grand
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4739.patch, LUCENE-4739.patch


 This is really quite awful, but the test I created for  2.1 GB FSTs never 
 tested save/load ... and ... it doesn't work.

--
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-4738) Killed JVM when first commit was running will generate a corrupted index


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

Michael McCandless commented on LUCENE-4738:


OK I'm seeing this as well.  If I create a directory with a 0-byte segments_1 
file ... then try to open IW with APPEND mode I get this:
{noformat}
Exception in thread main java.io.EOFException: read past EOF: 
MMapIndexInput(path=/l/trunk/lucene/core/index/segments_1)
at 
org.apache.lucene.store.ByteBufferIndexInput.readByte(ByteBufferIndexInput.java:77)
at 
org.apache.lucene.store.ChecksumIndexInput.readByte(ChecksumIndexInput.java:41)
at org.apache.lucene.store.DataInput.readInt(DataInput.java:84)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:285)
at org.apache.lucene.index.SegmentInfos$1.doBody(SegmentInfos.java:340)
at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:668)
at 
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:515)
at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:336)
at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:671)
at Test.main(Test.java:10)
{noformat}

and if I open with CREATE I get this:

{noformat}
Exception in thread main org.apache.lucene.index.CorruptIndexException: 
failed to locate current segments_N file
at 
org.apache.lucene.index.IndexFileDeleter.init(IndexFileDeleter.java:224)
at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:702)
at Test.main(Test.java:10)
{noformat}

You're right that if this had happened on a Nth (not first) commit, we would 
just fallback to the last successful commit, but here we have no prior commit 
since it's the first ... hmm.

 Killed JVM when first commit was running will generate a corrupted index
 

 Key: LUCENE-4738
 URL: https://issues.apache.org/jira/browse/LUCENE-4738
 Project: Lucene - Core
  Issue Type: Bug
  Components: core/index
Affects Versions: 4.0
 Environment: OS: Linux 2.6.32-220.23.1.el6.x86_64
 Java: java version 1.7.0_05
 Lucene: lucene-core-4.0.0 
Reporter: Billow Gao

 1. Start a NEW IndexWriterBuilder on an empty folder,
add some documents to the index
 2. Call commit
 3. When the segments_1 file with 0 byte was created, kill the JVM
 We will end with a corrupted index with an empty segments_1.
 We only have issue with the first commit crash.
 Also, if you tried to open an IndexSearcher on a new index. And the first 
 commit on the index was not finished yet. Then you will see exception like:
 ===
 org.apache.lucene.index.IndexNotFoundException: no segments* file found in 
 org.apache.lucene.store.MMapDirectory@C:\tmp\testdir 
 lockFactory=org.apache.lucene.store.NativeFSLockFactory@6ee00df: files: 
 [write.lock, _0.fdt, _0.fdx]
   at 
 org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:741)
   at 
 org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:52)
   at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:65)
 ===
 So when a new index was created, we should first create an empty index. We 
 should not wait for the commit/close call to create the segment file.
 If we had an empty index there. It won't leave a corrupted index when there 
 were a power issue on the first commit. 
 And a concurrent IndexSearcher can access to the index(No match is better 
 than exception).

--
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-MacOSX (64bit/jdk1.7.0) - Build # 152 - Failure!

2013-01-31 Thread Dawid Weiss

JVM bug.

[junit4:junit4] java(403,0x142bbd000) malloc: *** error for object
0x143babe00: pointer being freed was not allocated
[junit4:junit4] *** set a breakpoint in malloc_error_break to debug

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

[jira] [Updated] (LUCENE-4736) Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be killed


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

Dawid Weiss updated LUCENE-4736:


Fix Version/s: 5.0
   4.2

 Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be 
 killed
 

 Key: LUCENE-4736
 URL: https://issues.apache.org/jira/browse/LUCENE-4736
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Dawid Weiss
 Fix For: 4.2, 5.0


 EG:
 {noformat}
 ant test -Dtestcase=TestIndexWriterDelete -Dtests.seed=A22BC3E06CEC0036
 {noformat}
 Takes a while and then fails with this:
 {noformat}
 [junit4:junit4] ERROR   0.00s J2 | TestIndexWriterDelete (suite) 
 [junit4:junit4] Throwable #1:
 com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked
 from SUITE scope at org.apache.lucene.index.TestIndexWriterDelete:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 [junit4:junit4] Throwable #2:
 com.carrotsearch.randomizedtesting.ThreadLeakError: There are still
 zombie threads that couldn't be terminated:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 {noformat}
 Java version is:
 {noformat}
 java version 1.6.0
 Java(TM) SE Runtime Environment (build pxa6460sr9fp2ifix-2011_05(SR9 
 FP2+IV03622+IV02378+IZ99243+IZ97310+IV00707))
 IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
 jvmxa6460sr9-2011_94827 (JIT enabled, AOT enabled)
 J9VM - 2011_094827
 JIT  - r9_20101028_17488ifx45
 GC   - 20101027_AA)
 JCL  - 20110727_04
 {noformat}
 Curiously, I think it tends to happen on a test that fails an assumption?  Or 
 maybe I'm just imagining that ...

--
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-4736) Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be killed


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

Dawid Weiss resolved LUCENE-4736.
-

Resolution: Fixed

 Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be 
 killed
 

 Key: LUCENE-4736
 URL: https://issues.apache.org/jira/browse/LUCENE-4736
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Dawid Weiss
 Fix For: 4.2, 5.0


 EG:
 {noformat}
 ant test -Dtestcase=TestIndexWriterDelete -Dtests.seed=A22BC3E06CEC0036
 {noformat}
 Takes a while and then fails with this:
 {noformat}
 [junit4:junit4] ERROR   0.00s J2 | TestIndexWriterDelete (suite) 
 [junit4:junit4] Throwable #1:
 com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked
 from SUITE scope at org.apache.lucene.index.TestIndexWriterDelete:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 [junit4:junit4] Throwable #2:
 com.carrotsearch.randomizedtesting.ThreadLeakError: There are still
 zombie threads that couldn't be terminated:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 {noformat}
 Java version is:
 {noformat}
 java version 1.6.0
 Java(TM) SE Runtime Environment (build pxa6460sr9fp2ifix-2011_05(SR9 
 FP2+IV03622+IV02378+IZ99243+IZ97310+IV00707))
 IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
 jvmxa6460sr9-2011_94827 (JIT enabled, AOT enabled)
 J9VM - 2011_094827
 JIT  - r9_20101028_17488ifx45
 GC   - 20101027_AA)
 JCL  - 20110727_04
 {noformat}
 Curiously, I think it tends to happen on a test that fails an assumption?  Or 
 maybe I'm just imagining that ...

--
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-4737) Who tests the tester tests sometimes fail under IBM J9


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

Dawid Weiss resolved LUCENE-4737.
-

   Resolution: Fixed
Fix Version/s: 5.0
   4.2

Duplicate of LUCENE-4646

 Who tests the tester tests sometimes fail under IBM J9
 

 Key: LUCENE-4737
 URL: https://issues.apache.org/jira/browse/LUCENE-4737
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Dawid Weiss
 Fix For: 4.2, 5.0

 Attachments: j9log.txt


 Curiously, the tests only seem to fail when I run ant test from 
 lucene/core.  No Reproduce with line is printed ... and if I run the 
 failing tests alone, they do not fail.
 The failures look like this:
 {noformat}
 [junit4:junit4] Suite: 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed
 [junit4:junit4] FAILURE 0.02s J2 | 
 TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed 
 [junit4:junit4] Throwable #1: java.lang.AssertionError: expected:1 but 
 was:0
 [junit4:junit4]  at org.junit.Assert.fail(Assert.java:93)
 [junit4:junit4]  at org.junit.Assert.failNotEquals(Assert.java:647)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:128)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:472)
 [junit4:junit4]  at org.junit.Assert.assertEquals(Assert.java:456)
 [junit4:junit4]  at 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed(TestFailIfDirectoryNotClosed.java:41)
 [junit4:junit4]  at sun.reflect.NativeMethodAccessorImpl.invoke0(Native 
 Method)
 [junit4:junit4]  at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:60)
 [junit4:junit4]  at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:37)
 [junit4:junit4]  at java.lang.reflect.Method.invoke(Method.java:611)
 [junit4:junit4]  at 
 org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45)
 [junit4:junit4]  at 
 org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15)
 [junit4:junit4]  at 
 org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28)
 [junit4:junit4]  at 
 org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30)
 [junit4:junit4]  at 
 com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
 [junit4:junit4]  at org.junit.rules.RunRules.evaluate(RunRules.java:18)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263)
 [junit4:junit4]  at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68)
 [junit4:junit4]  at 
 org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$3.run(ParentRunner.java:231)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.access$000(ParentRunner.java:50)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222)
 [junit4:junit4]  at 
 org.junit.runners.ParentRunner.run(ParentRunner.java:300)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:180)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:275)
 [junit4:junit4]  at 
 com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12)
 [junit4:junit4] Completed on J2 in 0.02s, 1 test, 1 failure  FAILURES!
 {noformat}
 And at the end of ant test I see:
 {noformat}
 [junit4:junit4] Tests with failures (first 10 out of 34):
 [junit4:junit4]   - org.apache.lucene.store.TestLockFactory (suite)
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestCodecReported.testCorrectCodecReported
 [junit4:junit4]   - org.apache.lucene.index.TestIndexWriterReader (suite)
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestFailIfDirectoryNotClosed.testFailIfDirectoryNotClosed
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining.testSetupChaining
 [junit4:junit4]   - 
 org.apache.lucene.util.junitcompat.TestSetupTeardownChaining.testTeardownChaining
 [junit4:junit4]   -

[jira] [Commented] (LUCENE-4736) Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be killed


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

Commit Tag Bot commented on LUCENE-4736:


[branch_4x commit] Dawid Weiss
http://svn.apache.org/viewvc?view=revisionrevision=1441226

LUCENE-4736: ignore TimerThread zombies on J9.
Merging 1440961 from trunk.





 Some tests fail with IBM J9 due to strange TimerThread zombies that cannot be 
 killed
 

 Key: LUCENE-4736
 URL: https://issues.apache.org/jira/browse/LUCENE-4736
 Project: Lucene - Core
  Issue Type: Bug
Reporter: Michael McCandless
Assignee: Dawid Weiss
 Fix For: 4.2, 5.0


 EG:
 {noformat}
 ant test -Dtestcase=TestIndexWriterDelete -Dtests.seed=A22BC3E06CEC0036
 {noformat}
 Takes a while and then fails with this:
 {noformat}
 [junit4:junit4] ERROR   0.00s J2 | TestIndexWriterDelete (suite) 
 [junit4:junit4] Throwable #1:
 com.carrotsearch.randomizedtesting.ThreadLeakError: 1 thread leaked
 from SUITE scope at org.apache.lucene.index.TestIndexWriterDelete:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 [junit4:junit4] Throwable #2:
 com.carrotsearch.randomizedtesting.ThreadLeakError: There are still
 zombie threads that couldn't be terminated:
 [junit4:junit4]1) Thread[id=102, name=Thread-44,
 state=TIMED_WAITING, group=TGRP-TestIndexWriterDelete]
 [junit4:junit4] at java.lang.Object.wait(Native Method)
 [junit4:junit4] at java.lang.Object.wait(Object.java:196)
 [junit4:junit4] at java.util.Timer$TimerImpl.run(Timer.java:247)
 [junit4:junit4]at 
 __randomizedtesting.SeedInfo.seed([C9014BCB129899BF]:0)
 {noformat}
 Java version is:
 {noformat}
 java version 1.6.0
 Java(TM) SE Runtime Environment (build pxa6460sr9fp2ifix-2011_05(SR9 
 FP2+IV03622+IV02378+IZ99243+IZ97310+IV00707))
 IBM J9 VM (build 2.4, JRE 1.6.0 IBM J9 2.4 Linux amd64-64 
 jvmxa6460sr9-2011_94827 (JIT enabled, AOT enabled)
 J9VM - 2011_094827
 JIT  - r9_20101028_17488ifx45
 GC   - 20101027_AA)
 JCL  - 20110727_04
 {noformat}
 Curiously, I think it tends to happen on a test that fails an assumption?  Or 
 maybe I'm just imagining that ...

--
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-4738) Killed JVM when first commit was running will generate a corrupted index

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

Robert Muir commented on LUCENE-4738:
-

I'm so sad TestIndexWriterOnJRECrash is apparently not working to find issues
like this :(

Killed JVM when first commit was running will generate a corrupted index

Key: LUCENE-4738
URL: https://issues.apache.org/jira/browse/LUCENE-4738
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 4.0
Environment: OS: Linux 2.6.32-220.23.1.el6.x86_64
Java: java version 1.7.0_05
Lucene: lucene-core-4.0.0
Reporter: Billow Gao

1. Start a NEW IndexWriterBuilder on an empty folder,
add some documents to the index
2. Call commit
3. When the segments_1 file with 0 byte was created, kill the JVM
We will end with a corrupted index with an empty segments_1.
We only have issue with the first commit crash.
Also, if you tried to open an IndexSearcher on a new index. And the first
commit on the index was not finished yet. Then you will see exception like:
===
org.apache.lucene.index.IndexNotFoundException: no segments* file found in
org.apache.lucene.store.MMapDirectory@C:\tmp\testdir
lockFactory=org.apache.lucene.store.NativeFSLockFactory@6ee00df: files:
[write.lock, _0.fdt, _0.fdx]
at
org.apache.lucene.index.SegmentInfos$FindSegmentsFile.run(SegmentInfos.java:741)
at
org.apache.lucene.index.StandardDirectoryReader.open(StandardDirectoryReader.java:52)
at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:65)
===
So when a new index was created, we should first create an empty index. We
should not wait for the commit/close call to create the segment file.
If we had an empty index there. It won't leave a corrupted index when there
were a power issue on the first commit.
And a concurrent IndexSearcher can access to the index(No match is better
than exception).

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

[jira] [Created] (SOLR-4393) 'Execute Query' in the dashboard does not build the url correctly

2013-01-31 Thread Anand (JIRA)

Anand created SOLR-4393:
---

 Summary: 'Execute Query' in the dashboard does not build the url 
correctly
 Key: SOLR-4393
 URL: https://issues.apache.org/jira/browse/SOLR-4393
 Project: Solr
  Issue Type: Bug
  Components: web gui
Affects Versions: 4.1
Reporter: Anand


Recently upgraded to 4.1 and started seeing this issue since the upgrade. We 
also went from single core to multiple core at the same time.
 
Steps to reproduce
1. Select a core from the dashboard.
2. Select 'Query'
3. Without changing anything, click 'Execture Query'.
Expected: 10 hits (or less depending on data indexed) displayed on the screen.
Observed: See response below.

http://localhost:8080/solr/coreName/select?
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status0/intint 
name=QTime0/intlst name=params//lstresult name=response 
numFound=0 start=0/result
/response

Issue:  http://localhost:8080/solr/coreName/select?; is incomplete and q=*:* 
is not appended to the url.

Tested on Firefox and Chrome and both suffer from this issue.


--
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-4636) Upgrade ivy for IVY-1388 - build hangs at resolve:

2013-01-31 Thread Shawn Heisey (JIRA)


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

Shawn Heisey commented on LUCENE-4636:
--

Ivy 2.3.0 was officially released on January 21.

 Upgrade ivy for IVY-1388 - build hangs at resolve:
 

 Key: LUCENE-4636
 URL: https://issues.apache.org/jira/browse/LUCENE-4636
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 3.6, 4.0
Reporter: Shawn Heisey
 Fix For: 4.2, 5.0


 For certain failures during a lucene/solr build, or if you press ctrl-c at 
 the wrong moment during the build, ivy may leave a lockfile behind.  The next 
 time you run a build, ivy will hang with resolve: on the screen.
 The ivy project has a fix, currently not yet released.  When it does get 
 released, the version installed by the ivy-bootstrap target needs to be 
 updated.

--
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-MAVEN] Lucene-Solr-Maven-trunk #755: POMs out of sync

2013-01-31 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/755/

1 tests failed.
REGRESSION:  org.apache.solr.cloud.SyncSliceTest.testDistribSearch

Error Message:
shard1 should have just been set up to be inconsistent - but it's still 
consistent

Stack Trace:
java.lang.AssertionError: shard1 should have just been set up to be 
inconsistent - but it's still consistent
at 
__randomizedtesting.SeedInfo.seed([F560F280346D2E17:74867C9843324E2B]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.assertTrue(Assert.java:43)
at org.junit.Assert.assertNotNull(Assert.java:526)
at org.apache.solr.cloud.SyncSliceTest.doTest(SyncSliceTest.java:214)
at 
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:794)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49)
at 
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782)
at 
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46)
at 
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at 
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at 
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at 
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43)
at 
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at 
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)

[jira] [Updated] (LUCENE-4636) Upgrade ivy for IVY-1388 - build hangs at resolve:

2013-01-31 Thread Shawn Heisey (JIRA)


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

Shawn Heisey updated LUCENE-4636:
-

Attachment: LUCENE-4636.patch

Attached patch to change ivy version in the ivy-bootstrap target.

I wasn't sure how to get it to safely remove any other jar starting with ivy.

 Upgrade ivy for IVY-1388 - build hangs at resolve:
 

 Key: LUCENE-4636
 URL: https://issues.apache.org/jira/browse/LUCENE-4636
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 3.6, 4.0
Reporter: Shawn Heisey
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4636.patch


 For certain failures during a lucene/solr build, or if you press ctrl-c at 
 the wrong moment during the build, ivy may leave a lockfile behind.  The next 
 time you run a build, ivy will hang with resolve: on the screen.
 The ivy project has a fix, currently not yet released.  When it does get 
 released, the version installed by the ivy-bootstrap target needs to be 
 updated.

--
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-4394) Add SSL tests and example configs

2013-01-31 Thread Hoss Man (JIRA)

Hoss Man created SOLR-4394:
--

 Summary: Add SSL tests and example configs
 Key: SOLR-4394
 URL: https://issues.apache.org/jira/browse/SOLR-4394
 Project: Solr
  Issue Type: Improvement
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.2


We should provide some examples of running Solr+Jetty with SSL enabled, and 
have some basic tests using jetty over SSL

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

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

[jira] [Updated] (SOLR-4394) Add SSL tests and example configs

2013-01-31 Thread Hoss Man (JIRA)


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

Hoss Man updated SOLR-4394:
---

Attachment: SOLR-4394.patch

Patch with the basics.  After applying this patch you need to run the following 
commends to generate the keystore...

{noformat}
cd solr/example/etc/  ./create-solrtest.keystore.sh
{noformat}

(The keystore file can be committed in SVN, but as a binary file it can't be 
part of hte patch)

There is still a nocommit to randomize if/when we use SSL, and also some TODOs 
-- in particular arround whether we ant to  consider promoting the SSL test 
logic up to SolrJettyTestBase so it's (randomly) used in more tests, but i 
wanted to put this out there as a starting point for discussion.   (and because 
i'm going offline for a week on vacation and i don't wnat to lose track of what 
i was doing)

If/when we get basics like this committed, we can then move towards some SSL 
related cloud tests for SOLR-3854



 Add SSL tests and example configs
 -

 Key: SOLR-4394
 URL: https://issues.apache.org/jira/browse/SOLR-4394
 Project: Solr
  Issue Type: Improvement
Reporter: Hoss Man
Assignee: Hoss Man
 Fix For: 4.2

 Attachments: SOLR-4394.patch


 We should provide some examples of running Solr+Jetty with SSL enabled, and 
 have some basic tests using jetty over SSL

--
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-4636) Upgrade ivy for IVY-1388 - build hangs at resolve:


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

Robert Muir commented on LUCENE-4636:
-

{quote}
Ivy 2.3.0 was officially released on January 21.
{quote}

Lets upgrade!

 Upgrade ivy for IVY-1388 - build hangs at resolve:
 

 Key: LUCENE-4636
 URL: https://issues.apache.org/jira/browse/LUCENE-4636
 Project: Lucene - Core
  Issue Type: Improvement
Affects Versions: 3.6, 4.0
Reporter: Shawn Heisey
 Fix For: 4.2, 5.0

 Attachments: LUCENE-4636.patch


 For certain failures during a lucene/solr build, or if you press ctrl-c at 
 the wrong moment during the build, ivy may leave a lockfile behind.  The next 
 time you run a build, ivy will hang with resolve: on the screen.
 The ivy project has a fix, currently not yet released.  When it does get 
 released, the version installed by the ivy-bootstrap target needs to be 
 updated.

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

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

Build failed in Jenkins: the_4547_machine_gun #1734

2013-01-31 Thread Charlie Cron

See http://fortyounce.servebeer.com/job/the_4547_machine_gun/1734/

--
[...truncated 8701 lines...]
ivy-availability-check:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml

resolve:

common.init:

compile-lucene-core:

init:

-clover.disable:

-clover.load:

-clover.classpath:

-clover.setup:

clover:

compile-core:

compile-test-framework:

ivy-availability-check:

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml

resolve:

init:

compile-lucene-core:

compile-codecs:
 [echo] Building codecs...

ivy-availability-check:
 [echo] Building codecs...

ivy-fail:

ivy-configure:
[ivy:configure] :: loading settings :: file = 
http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml

resolve:

common.init:

compile-lucene-core:

init:

-clover.disable:

-clover.load:

-clover.classpath:

-clover.setup:

clover:

compile-core:

-clover.disable:

-clover.load:

-clover.classpath:

-clover.setup:

clover:

common.compile-core:

compile-core:

common.compile-test:

install-junit4-taskdef:

validate:

common.test:
[mkdir] Created dir: 
http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/build/codecs/test
[mkdir] Created dir: 
http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/build/codecs/test/temp
[junit4:junit4] JUnit4 says hello! Master seed: A085ECECA10C73B0
[junit4:junit4] Executing 14 suites with 4 JVMs.
[junit4:junit4] 
[junit4:junit4] Started J0 PID(20534@beast).
[junit4:junit4] Started J2 PID(20538@beast).
[junit4:junit4] Started J1 PID(20535@beast).
[junit4:junit4] Started J3 PID(20533@beast).
[junit4:junit4] Suite: 
org.apache.lucene.codecs.pulsing.TestPulsingPostingsFormat
[junit4:junit4] Completed on J1 in 2.03s, 7 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.codecs.memory.TestDirectPostingsFormat
[junit4:junit4] Completed on J2 in 2.32s, 7 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.codecs.memory.TestMemoryPostingsFormat
[junit4:junit4] Completed on J3 in 2.19s, 7 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.codecs.pulsing.Test10KPulsings
[junit4:junit4] IGNOR/A 0.04s J2 | Test10KPulsings.test10kPulsed
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] IGNOR/A 0.01s J2 | Test10KPulsings.test10kNotPulsed
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] Completed on J2 in 0.10s, 2 tests, 2 skipped
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.codecs.intblock.TestIntBlockCodec
[junit4:junit4] Completed on J2 in 0.09s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.codecs.sep.TestSepPostingsFormat
[junit4:junit4] Completed on J1 in 0.83s, 7 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.codecs.pulsing.TestPulsingReuse
[junit4:junit4] Completed on J3 in 0.41s, 2 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.codecs.blockterms.TestFixedGapPostingsFormat
[junit4:junit4] Completed on J2 in 1.38s, 7 tests
[junit4:junit4] 
[junit4:junit4] Suite: org.apache.lucene.codecs.bloom.TestBloomPostingsFormat
[junit4:junit4] Completed on J1 in 1.65s, 7 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.codecs.intblock.TestVariableIntBlockPostingsFormat
[junit4:junit4] Completed on J3 in 1.66s, 7 tests
[junit4:junit4] 
[junit4:junit4] Suite: 
org.apache.lucene.codecs.simpletext.TestSimpleTextPostingsFormat
[junit4:junit4] IGNOR/A 0.05s J1 | TestSimpleTextPostingsFormat.testRandom
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] IGNOR/A 0.00s J1 | 
TestSimpleTextPostingsFormat.testDocsAndFreqsAndPositions
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] IGNOR/A 0.00s J1 | 
TestSimpleTextPostingsFormat.testDocsAndFreqsAndPositionsAndPayloads
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] IGNOR/A 0.00s J1 | 
TestSimpleTextPostingsFormat.testDocsAndFreqsAndPositionsAndOffsets
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] IGNOR/A 0.00s J1 | TestSimpleTextPostingsFormat.testDocsOnly
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] IGNOR/A 0.00s J1 | 
TestSimpleTextPostingsFormat.testDocsAndFreqsAndPositionsAndOffsetsAndPayloads
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] IGNOR/A 0.00s J1 | TestSimpleTextPostingsFormat.testDocsAndFreqs
[junit4:junit4] Assumption #1: 'nightly' test group is disabled (@Nightly)
[junit4:junit4] Completed on J1 in 0.15s, 7 tests, 7 skipped
[junit4:junit4] 
[junit4:junit4] Suite:

[jira] [Resolved] (LUCENE-4636) Upgrade ivy for IVY-1388 - build hangs at resolve: