date:20131012

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

Uwe Schindler edited comment on LUCENE-5273 at 10/12/13 8:31 AM:
-

bq. Hmm, the Maven Ant Tasks install and deploy tasks require that the source
resources be files - at least, the documentation makes no mention of anything
but files - so I don't think there's any way to avoid unpacking the archives.

Yeah, I noticed this, too.

I am not sure of the overhead, but as the binary artifact also contains
javadocs and those are many small files, this makes the task run slowly on
windows and some filesystems. How about *only* extracting JAR files on the
untar task? I would only add some patternset matching only {{\*\*/\*.jar}} to
the untar task (see last example on
http://ant.apache.org/manual/Tasks/unzip.html).

I will try this out soon, just need breakfast!

was (Author: thetaphi):
bq. Hmm, the Maven Ant Tasks install and deploy tasks require that the source
resources be files - at least, the documentation makes no mention of anything
but files - so I don't think there's any way to avoid unpacking the archives.

Yeah, I noticed this, too.

I am not sure of the overhead, but as the binary artifact also contains
javadocs and those are many small files, this makes the task run slowly on
windows and some filesystems. How about *only* extracting JAR files on the
untar task? I would only add some patternset matching only {{**/*.jar}} to the
untar task (see last example on http://ant.apache.org/manual/Tasks/unzip.html).

I will try this out soon, just need breakfast!

Binary artifacts in Lucene and Solr convenience binary distributions
accompanying a release, including on Maven Central, should be identical
across all distributions
-

Key: LUCENE-5273
URL: https://issues.apache.org/jira/browse/LUCENE-5273
Project: Lucene - Core
Issue Type: Bug
Components: general/build
Reporter: Steve Rowe
Assignee: Steve Rowe
Fix For: 4.6, 5.0

Attachments: LUCENE-5273.patch

As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we
release multiple versions of the same artifact: binary Maven artifacts are
not identical to the ones in the Lucene and Solr binary distributions, and
the Lucene jars in the Solr binary distribution, including within the war,
are not identical to the ones in the Lucene binary distribution. This is bad.
It's (probably always?) not horribly bad, since the differences all appear to
be caused by the build re-creating manifests and re-building jars and the
Solr war from their constituents at various points in the release build
process; as a result, manifest timestamp attributes, as well as archive
metadata (at least constituent timestamps, maybe other things?), differ each
time a jar is rebuilt.

--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions


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

Uwe Schindler commented on LUCENE-5273:
---

bq. Hmm, the Maven Ant Tasks install and deploy tasks require that the source 
resources be files - at least, the documentation makes no mention of anything 
but files - so I don't think there's any way to avoid unpacking the archives.

Yeah, I noticed this, too.

I am not sure of the overhead, but as the binary artifact also contains 
javadocs and those are many small files, this makes the task run slowly on 
windows and some filesystems. How about *only* extracting JAR files on the 
untar task? I would only add some patternset matching only {{**/*.jar}} to the 
untar task (see last example on http://ant.apache.org/manual/Tasks/unzip.html).

I will try this out soon, just need breakfast!

 Binary artifacts in Lucene and Solr convenience binary distributions 
 accompanying a release, including on Maven Central, should be identical 
 across all distributions
 -

 Key: LUCENE-5273
 URL: https://issues.apache.org/jira/browse/LUCENE-5273
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/build
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 4.6, 5.0

 Attachments: LUCENE-5273.patch


 As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we 
 release multiple versions of the same artifact: binary Maven artifacts are 
 not identical to the ones in the Lucene and Solr binary distributions, and 
 the Lucene jars in the Solr binary distribution, including within the war, 
 are not identical to the ones in the Lucene binary distribution.  This is bad.
 It's (probably always?) not horribly bad, since the differences all appear to 
 be caused by the build re-creating manifests and re-building jars and the 
 Solr war from their constituents at various points in the release build 
 process; as a result, manifest timestamp attributes, as well as archive 
 metadata (at least constituent timestamps, maybe other things?), differ each 
 time a jar is rebuilt.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions

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

Uwe Schindler updated LUCENE-5273:
--

Attachment: LUCENE-5273-optimized.patch

Here the patch. ant generate-maven-articfatcs succeeds (it would fail if some
needed files were not extracted from tgz). I did not smoke, as I have only
windows.

In general there is one problem with the whole approach of untaring: It seems
to me that you can no longer build maven artifacts for a single module, it
still builds everything and fails lately (e.g. dist-maven). So I would suggest
to rename those tasks to use - as prefix, so you can no longer call them:
dist-maven is one that is affected, rename to -dist-maven. We should do
this in a separate issue.

[~steve_rowe]: Should I commit this optimization? It also largely reduces disk
usage!

Binary artifacts in Lucene and Solr convenience binary distributions
accompanying a release, including on Maven Central, should be identical
across all distributions
-

Key: LUCENE-5273
URL: https://issues.apache.org/jira/browse/LUCENE-5273
Project: Lucene - Core
Issue Type: Bug
Components: general/build
Reporter: Steve Rowe
Assignee: Steve Rowe
Fix For: 4.6, 5.0

Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch

--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (LUCENE-5273) Binary artifacts in Lucene and Solr convenience binary distributions accompanying a release, including on Maven Central, should be identical across all distributions


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

Uwe Schindler commented on LUCENE-5273:
---

BTW: I was hoping this patch also prevent rebuilding the same javadocs over and 
over :-) We should also fix this in the future, it's horrible. While building 
Solr maven artifacts it rebuilds solr-core javadocs 5 or 6 times! (for each 
module),

[~steve_rowe]: I am out of office, you can commit this patch and also backport 
if you like!

 Binary artifacts in Lucene and Solr convenience binary distributions 
 accompanying a release, including on Maven Central, should be identical 
 across all distributions
 -

 Key: LUCENE-5273
 URL: https://issues.apache.org/jira/browse/LUCENE-5273
 Project: Lucene - Core
  Issue Type: Bug
  Components: general/build
Reporter: Steve Rowe
Assignee: Steve Rowe
 Fix For: 4.6, 5.0

 Attachments: LUCENE-5273-optimized.patch, LUCENE-5273.patch


 As mentioned in various issues (e.g. LUCENE-3655, LUCENE-3885, SOLR-4766), we 
 release multiple versions of the same artifact: binary Maven artifacts are 
 not identical to the ones in the Lucene and Solr binary distributions, and 
 the Lucene jars in the Solr binary distribution, including within the war, 
 are not identical to the ones in the Lucene binary distribution.  This is bad.
 It's (probably always?) not horribly bad, since the differences all appear to 
 be caused by the build re-creating manifests and re-building jars and the 
 Solr war from their constituents at various points in the release build 
 process; as a result, manifest timestamp attributes, as well as archive 
 metadata (at least constituent timestamps, maybe other things?), differ each 
 time a jar is rebuilt.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (LUCENE-5260) Make older Suggesters more accepting of TermFreqPayloadIterator

2013-10-12 Thread Areek Zillur (JIRA)


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

Areek Zillur updated LUCENE-5260:
-

Attachment: LUCENE-5260.patch

Thanks for the review, Michael! I fixed the UnsortedTermFreqIteratorWrapper 
issue and added the asserts.

Uploaded patch
  - added support for payloads in SortedTermFreqPayloadIteratorWrapper
  - nuked all termFreqIter and co
  - renamed all the termFreq implementations 
  - added tests

 

 Make older Suggesters more accepting of TermFreqPayloadIterator
 ---

 Key: LUCENE-5260
 URL: https://issues.apache.org/jira/browse/LUCENE-5260
 Project: Lucene - Core
  Issue Type: Improvement
  Components: core/search
Reporter: Areek Zillur
 Attachments: LUCENE-5260.patch, LUCENE-5260.patch


 As discussed in https://issues.apache.org/jira/browse/LUCENE-5251, it would 
 be nice to make the older suggesters accepting of TermFreqPayloadIterator and 
 throw an exception if payload is found (if it cannot be used). 
 This will also allow us to nuke most of the other interfaces for 
 BytesRefIterator. 



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b106) - Build # 7853 - Failure!

2013-10-12 Thread Policeman Jenkins Server

Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/7853/
Java: 64bit/jdk1.8.0-ea-b106 -XX:+UseCompressedOops -XX:+UseConcMarkSweepGC

All tests passed

Build Log:
[...truncated 7572 lines...]
   [junit4] JVM J1: stdout was not empty, see: 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/grouping/test/temp/junit4-J1-20131012_124839_860.sysout
   [junit4]  JVM J1: stdout (verbatim) 
   [junit4] #
   [junit4] # A fatal error has been detected by the Java Runtime Environment:
   [junit4] #
   [junit4] #  SIGSEGV (0xb) at pc=0x7f4decc19972, pid=7940, 
tid=139972254365440
   [junit4] #
   [junit4] # JRE version: Java(TM) SE Runtime Environment (8.0-b106) (build 
1.8.0-ea-b106)
   [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (25.0-b48 mixed mode 
linux-amd64 compressed oops)
   [junit4] # Problematic frame:
   [junit4] # C  [libc.so.6+0x7f972]  _IO_str_pbackfail+0x1db2
   [junit4] #
   [junit4] # Failed to write core dump. Core dumps have been disabled. To 
enable core dumping, try ulimit -c unlimited before starting Java again
   [junit4] #
   [junit4] # An error report file with more information is saved as:
   [junit4] # 
/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/grouping/test/J1/hs_err_pid7940.log
   [junit4] #
   [junit4] # If you would like to submit a bug report, please visit:
   [junit4] #   http://bugreport.sun.com/bugreport/crash.jsp
   [junit4] #
   [junit4]  JVM J1: EOF 

[...truncated 11 lines...]
   [junit4] ERROR: JVM J1 ended with an exception, command line: 
/var/lib/jenkins/tools/java/64bit/jdk1.8.0-ea-b106/jre/bin/java 
-XX:+UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError 
-XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/heapdumps 
-Dtests.prefix=tests -Dtests.seed=3F3465A1AF053718 -Xmx512M -Dtests.iters= 
-Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random 
-Dtests.postingsformat=random -Dtests.docvaluesformat=random 
-Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random 
-Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 
-Dtests.cleanthreads=perMethod 
-Djava.util.logging.config.file=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/logging.properties
 -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true 
-Dtests.asserts.gracious=false -Dtests.multiplier=3 -DtempDir=. 
-Djava.io.tmpdir=. 
-Djunit4.tempDir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/grouping/test/temp
 
-Dclover.db.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/clover/db
 -Djava.security.manager=org.apache.lucene.util.TestSecurityManager 
-Djava.security.policy=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/junit4/tests.policy
 -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 
-Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory 
-Djava.awt.headless=true -Dtests.disableHdfs=true -Dfile.encoding=US-ASCII 
-classpath

[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!

2013-10-12 Thread builder

Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63029/

1 tests failed.
REGRESSION:  
org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting

Error Message:


Stack Trace:
java.lang.NullPointerException
at 
org.apache.lucene.index.SnapshotDeletionPolicy.release(SnapshotDeletionPolicy.java:99)
at 
org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting(TestSnapshotDeletionPolicy.java:313)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at 
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at 
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at 
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at 
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at 
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at 
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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 
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)
at java.lang.Thread.run(Thread.java:722)




Build Log:
[...truncated 513 lines...]
   [junit4] Suite: org.apache.lucene.index.TestSnapshotDeletionPolicy
   [junit4]   2 loka 12, 2013 3:08:57 IP. 
com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
 uncaughtException
   [junit4]   2 WARNING: Uncaught exception in thread: 
Thread[t8,5,TGRP-TestSnapshotDeletionPolicy]
   [junit4]   2 java.lang.AssertionError: lastCommitChangeCount=13 
changeCount=12
   [junit4]   2at 
__randomizedtesting.SeedInfo.seed([313329D29B4DAADD]:0)
   [junit4]   2at 
org.apache.lucene.index.IndexWriter.startCommit(IndexWriter.java:4170)
   [junit4]   2at

Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!

Not good!  I'll dig.  We should hold 4.5.1...

Mike McCandless

http://blog.mikemccandless.com


On Sat, Oct 12, 2013 at 9:11 AM,  buil...@flonkings.com wrote:
 Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63029/

 1 tests failed.
 REGRESSION:  
 org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting

 Error Message:


 Stack Trace:
 java.lang.NullPointerException
 at 
 org.apache.lucene.index.SnapshotDeletionPolicy.release(SnapshotDeletionPolicy.java:99)
 at 
 org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting(TestSnapshotDeletionPolicy.java:313)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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 
 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)
 at java.lang.Thread.run(Thread.java:722)




 Build Log:
 [...truncated 513 lines...]
[junit4] Suite: org.apache.lucene.index.TestSnapshotDeletionPolicy
[junit4]   2 loka 12, 2013 3:08:57 IP. 
 com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
  uncaughtException
[junit4]   2 WARNING: Uncaught exception in thread: 
 Thread[t8,5,TGRP-TestSnapshotDeletionPolicy]
[junit4]   2

Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.6.0_45) - Build # 7753 - Failure!

2013-10-12 Thread ASF subversion and git services (JIRA)

I'll dig ...

Mike McCandless

http://blog.mikemccandless.com


On Sat, Oct 12, 2013 at 1:34 AM, Policeman Jenkins Server
jenk...@thetaphi.de wrote:
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/7753/
 Java: 32bit/jdk1.6.0_45 -server -XX:+UseParallelGC

 1 tests failed.
 REGRESSION:  
 org.apache.lucene.index.TestIndexWriterWithThreads.testCloseWithThreads

 Error Message:
 MockDirectoryWrapper: cannot close: there are still open files: {_1e.cfs=9, 
 _t.cfs=9, _1g.cfs=9, _1f.cfs=9, _1d.cfs=9}

 Stack Trace:
 java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are 
 still open files: {_1e.cfs=9, _t.cfs=9, _1g.cfs=9, _1f.cfs=9, _1d.cfs=9}
 at 
 __randomizedtesting.SeedInfo.seed([4E5816A23CC2ACB:1921A81D4039306D]:0)
 at 
 org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:622)
 at 
 org.apache.lucene.index.TestIndexWriterWithThreads.testCloseWithThreads(TestIndexWriterWithThreads.java:240)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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 
 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)
 at java.lang.Thread.run(Thread.java:662)
 Caused by: java.lang.RuntimeException: unclosed IndexInput: _1d.cfs

[JENKINS-MAVEN] Lucene-Solr-Maven-4.x #474: POMs out of sync

2013-10-12 Thread Apache Jenkins Server

Build: https://builds.apache.org/job/Lucene-Solr-Maven-4.x/474/

1 tests failed.
REGRESSION:  
org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts

Error Message:
Exception during query

Stack Trace:
java.lang.RuntimeException: Exception during query
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:630)
at org.apache.solr.SolrTestCaseJ4.assertQ(SolrTestCaseJ4.java:604)
at 
org.apache.solr.spelling.SpellCheckCollatorTest.testEstimatedHitCounts(SpellCheckCollatorTest.java:521)




Build Log:
[...truncated 36997 lines...]



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

Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!

2013-10-12 Thread Mark Miller


On Oct 12, 2013, at 9:55 AM, Michael McCandless luc...@mikemccandless.com 
wrote:

 Not good!  I'll dig.  We should hold 4.5.1...

I'm not in a major hurry - I figured we should at least give a few days to let 
the back ports bake a bit and see if anything else critical comes up.

While it would certainly be easier for me to bang it out this weekend, I was 
thinking something like tuesday / wednesday made sense depending on what pops 
up.

From a practical perspective, I've setup the lucene/solr 4.5 branch tests to 
run on my full metal jenkins box, I've built test artifacts and uploaded and 
smoke tested them, and I've got my email signing tested and in working order. 
So hopefully it will be pretty quick and easy when we are ready.

- Mark

[jira] [Commented] (SOLR-5324) Make sub shard replica recovery and shard state switch asynchronous


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

ASF subversion and git services commented on SOLR-5324:
---

Commit 1531580 from sha...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1531580 ]

SOLR-5324: Make sub shard replica recovery and shard state switch asynchronous

 Make sub shard replica recovery and shard state switch asynchronous
 ---

 Key: SOLR-5324
 URL: https://issues.apache.org/jira/browse/SOLR-5324
 Project: Solr
  Issue Type: Improvement
  Components: SolrCloud
Reporter: Shalin Shekhar Mangar
Assignee: Shalin Shekhar Mangar
 Fix For: 4.6, 5.0

 Attachments: SOLR-5324.patch, SOLR-5324.patch, SOLR-5324.patch, 
 SOLR-5324.patch


 Currently the shard split command waits for all replicas of all sub shards to 
 recover and then switches the state of parent to inactive and sub-shards to 
 active.
 The problem is that shard split (ab)uses the CoreAdmin WaitForState action to 
 ask the sub shard leader to wait until the replica states are active. This 
 action is prone to timeout.
 We should make the shard state switching asynchronous. Once all replicas of 
 all sub-shards are 'active', the shard states should be switched 
 automatically.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!

2013-10-12 Thread Robert Muir

 From a practical perspective, I've setup the lucene/solr 4.5 branch tests to
 run on my full metal jenkins box, I've built test artifacts and uploaded and
 smoke tested them, and I've got my email signing tested and in working
 order. So hopefully it will be pretty quick and easy when we are ready.

I needed to catch up on sleep today and could not yet help with
debugging, but I did the same:

http://sierranevada.servebeer.com/job/4.5.1-test-core-loop/

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

[jira] [Updated] (SOLR-4327) SolrJ code review indicates potential for leaked HttpClient connections


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

Mark Miller updated SOLR-4327:
--

Fix Version/s: 5.0
   4.6
   4.5.1
 Assignee: Mark Miller

 SolrJ code review indicates potential for leaked HttpClient connections
 ---

 Key: SOLR-4327
 URL: https://issues.apache.org/jira/browse/SOLR-4327
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Karl Wright
Assignee: Mark Miller
 Fix For: 4.5.1, 4.6, 5.0


 The SolrJ HttpSolrServer implementation does not seem to handle errors 
 properly and seems capable of leaking HttpClient connections.  See the 
 request() method in org.apache.solr.client.solrj.impl.HttpSolrServer.  The 
 issue is that exceptions thrown from within this method do not necessarily 
 consume the stream when an exception is thrown.  There is a try/finally block 
 which reads (in part):
 {code}
 } finally {
   if (respBody != null  processor!=null) {
 try {
   respBody.close();
 } catch (Throwable t) {} // ignore
   }
 }
 {code}
 But, in order to always guarantee consumption of the stream, it should 
 include:
 {code}
 method.abort();
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

-
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-Linux (32bit/jdk1.6.0_45) - Build # 7753 - Failure!

I committed a fix; I caused this when I fixed LUCENE-5263.

Mike McCandless

http://blog.mikemccandless.com


On Sat, Oct 12, 2013 at 9:55 AM, Michael McCandless
luc...@mikemccandless.com wrote:
 I'll dig ...

 Mike McCandless

 http://blog.mikemccandless.com


 On Sat, Oct 12, 2013 at 1:34 AM, Policeman Jenkins Server
 jenk...@thetaphi.de wrote:
 Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/7753/
 Java: 32bit/jdk1.6.0_45 -server -XX:+UseParallelGC

 1 tests failed.
 REGRESSION:  
 org.apache.lucene.index.TestIndexWriterWithThreads.testCloseWithThreads

 Error Message:
 MockDirectoryWrapper: cannot close: there are still open files: {_1e.cfs=9, 
 _t.cfs=9, _1g.cfs=9, _1f.cfs=9, _1d.cfs=9}

 Stack Trace:
 java.lang.RuntimeException: MockDirectoryWrapper: cannot close: there are 
 still open files: {_1e.cfs=9, _t.cfs=9, _1g.cfs=9, _1f.cfs=9, _1d.cfs=9}
 at 
 __randomizedtesting.SeedInfo.seed([4E5816A23CC2ACB:1921A81D4039306D]:0)
 at 
 org.apache.lucene.store.MockDirectoryWrapper.close(MockDirectoryWrapper.java:622)
 at 
 org.apache.lucene.index.TestIndexWriterWithThreads.testCloseWithThreads(TestIndexWriterWithThreads.java:240)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
 at java.lang.reflect.Method.invoke(Method.java:597)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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 
 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

Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!

Can anyone reproduce this failure?

I tried beasting with 1.7.0_05 but no fails ...

Mike McCandless

http://blog.mikemccandless.com


On Sat, Oct 12, 2013 at 9:11 AM,  buil...@flonkings.com wrote:
 Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63029/

 1 tests failed.
 REGRESSION:  
 org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting

 Error Message:


 Stack Trace:
 java.lang.NullPointerException
 at 
 org.apache.lucene.index.SnapshotDeletionPolicy.release(SnapshotDeletionPolicy.java:99)
 at 
 org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting(TestSnapshotDeletionPolicy.java:313)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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 
 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)
 at java.lang.Thread.run(Thread.java:722)




 Build Log:
 [...truncated 513 lines...]
[junit4] Suite: org.apache.lucene.index.TestSnapshotDeletionPolicy
[junit4]   2 loka 12, 2013 3:08:57 IP. 
 com.carrotsearch.randomizedtesting.RandomizedRunner$QueueUncaughtExceptionsHandler
  uncaughtException
[junit4]   2 WARNING: Uncaught exception in thread: 
 Thread[t8,5,TGRP-TestSnapshotDeletionPolicy]

[jira] [Updated] (SOLR-4327) SolrJ code review indicates potential for leaked HttpClient connections


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

Mark Miller updated SOLR-4327:
--

Attachment: SOLR-4327.patch

 SolrJ code review indicates potential for leaked HttpClient connections
 ---

 Key: SOLR-4327
 URL: https://issues.apache.org/jira/browse/SOLR-4327
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Karl Wright
Assignee: Mark Miller
 Fix For: 4.5.1, 4.6, 5.0

 Attachments: SOLR-4327.patch


 The SolrJ HttpSolrServer implementation does not seem to handle errors 
 properly and seems capable of leaking HttpClient connections.  See the 
 request() method in org.apache.solr.client.solrj.impl.HttpSolrServer.  The 
 issue is that exceptions thrown from within this method do not necessarily 
 consume the stream when an exception is thrown.  There is a try/finally block 
 which reads (in part):
 {code}
 } finally {
   if (respBody != null  processor!=null) {
 try {
   respBody.close();
 } catch (Throwable t) {} // ignore
   }
 }
 {code}
 But, in order to always guarantee consumption of the stream, it should 
 include:
 {code}
 method.abort();
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-4327) SolrJ code review indicates potential for leaked HttpClient connections


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

Mark Miller commented on SOLR-4327:
---

Thanks Karl - this one missed my radar. I'll commit shortly.

 SolrJ code review indicates potential for leaked HttpClient connections
 ---

 Key: SOLR-4327
 URL: https://issues.apache.org/jira/browse/SOLR-4327
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Karl Wright
Assignee: Mark Miller
 Fix For: 4.5.1, 4.6, 5.0

 Attachments: SOLR-4327.patch


 The SolrJ HttpSolrServer implementation does not seem to handle errors 
 properly and seems capable of leaking HttpClient connections.  See the 
 request() method in org.apache.solr.client.solrj.impl.HttpSolrServer.  The 
 issue is that exceptions thrown from within this method do not necessarily 
 consume the stream when an exception is thrown.  There is a try/finally block 
 which reads (in part):
 {code}
 } finally {
   if (respBody != null  processor!=null) {
 try {
   respBody.close();
 } catch (Throwable t) {} // ignore
   }
 }
 {code}
 But, in order to always guarantee consumption of the stream, it should 
 include:
 {code}
 method.abort();
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Updated] (SOLR-4327) SolrJ code review indicates potential for leaked HttpClient connections

2013-10-12 Thread ASF subversion and git services (JIRA)


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

Mark Miller updated SOLR-4327:
--

Attachment: SOLR-4327.patch

 SolrJ code review indicates potential for leaked HttpClient connections
 ---

 Key: SOLR-4327
 URL: https://issues.apache.org/jira/browse/SOLR-4327
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Karl Wright
Assignee: Mark Miller
 Fix For: 4.5.1, 4.6, 5.0

 Attachments: SOLR-4327.patch, SOLR-4327.patch


 The SolrJ HttpSolrServer implementation does not seem to handle errors 
 properly and seems capable of leaking HttpClient connections.  See the 
 request() method in org.apache.solr.client.solrj.impl.HttpSolrServer.  The 
 issue is that exceptions thrown from within this method do not necessarily 
 consume the stream when an exception is thrown.  There is a try/finally block 
 which reads (in part):
 {code}
 } finally {
   if (respBody != null  processor!=null) {
 try {
   respBody.close();
 } catch (Throwable t) {} // ignore
   }
 }
 {code}
 But, in order to always guarantee consumption of the stream, it should 
 include:
 {code}
 method.abort();
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-4327) SolrJ code review indicates potential for leaked HttpClient connections


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

ASF subversion and git services commented on SOLR-4327:
---

Commit 1531596 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1531596 ]

SOLR-4327: HttpSolrServer can leak connections on errors.

 SolrJ code review indicates potential for leaked HttpClient connections
 ---

 Key: SOLR-4327
 URL: https://issues.apache.org/jira/browse/SOLR-4327
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Karl Wright
Assignee: Mark Miller
 Fix For: 4.5.1, 4.6, 5.0

 Attachments: SOLR-4327.patch, SOLR-4327.patch


 The SolrJ HttpSolrServer implementation does not seem to handle errors 
 properly and seems capable of leaking HttpClient connections.  See the 
 request() method in org.apache.solr.client.solrj.impl.HttpSolrServer.  The 
 issue is that exceptions thrown from within this method do not necessarily 
 consume the stream when an exception is thrown.  There is a try/finally block 
 which reads (in part):
 {code}
 } finally {
   if (respBody != null  processor!=null) {
 try {
   respBody.close();
 } catch (Throwable t) {} // ignore
   }
 }
 {code}
 But, in order to always guarantee consumption of the stream, it should 
 include:
 {code}
 method.abort();
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!

2013-10-12 Thread Robert Muir

Just the seed? or the master seed. if its a jvm bug we need the latter.

flonkings already discarded the console log so we lost that, unless
you still have it open in a browser or something?

On Sat, Oct 12, 2013 at 4:39 PM, Michael McCandless
luc...@mikemccandless.com wrote:
 Can anyone reproduce this failure?

 I tried beasting with 1.7.0_05 but no fails ...

 Mike McCandless

 http://blog.mikemccandless.com


 On Sat, Oct 12, 2013 at 9:11 AM,  buil...@flonkings.com wrote:
 Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63029/

 1 tests failed.
 REGRESSION:  
 org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting

 Error Message:


 Stack Trace:
 java.lang.NullPointerException
 at 
 org.apache.lucene.index.SnapshotDeletionPolicy.release(SnapshotDeletionPolicy.java:99)
 at 
 org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting(TestSnapshotDeletionPolicy.java:313)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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 
 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)
 at java.lang.Thread.run(Thread.java:722)




 Build Log:
 [...truncated 513 lines...]
[junit4] Suite:

[jira] [Commented] (SOLR-4327) SolrJ code review indicates potential for leaked HttpClient connections

2013-10-12 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-4327:
---

Commit 1531597 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1531597 ]

SOLR-4327: HttpSolrServer can leak connections on errors.

 SolrJ code review indicates potential for leaked HttpClient connections
 ---

 Key: SOLR-4327
 URL: https://issues.apache.org/jira/browse/SOLR-4327
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Karl Wright
Assignee: Mark Miller
 Fix For: 4.5.1, 4.6, 5.0

 Attachments: SOLR-4327.patch, SOLR-4327.patch


 The SolrJ HttpSolrServer implementation does not seem to handle errors 
 properly and seems capable of leaking HttpClient connections.  See the 
 request() method in org.apache.solr.client.solrj.impl.HttpSolrServer.  The 
 issue is that exceptions thrown from within this method do not necessarily 
 consume the stream when an exception is thrown.  There is a try/finally block 
 which reads (in part):
 {code}
 } finally {
   if (respBody != null  processor!=null) {
 try {
   respBody.close();
 } catch (Throwable t) {} // ignore
   }
 }
 {code}
 But, in order to always guarantee consumption of the stream, it should 
 include:
 {code}
 method.abort();
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Commented] (SOLR-4327) SolrJ code review indicates potential for leaked HttpClient connections

2013-10-12 Thread ASF subversion and git services (JIRA)


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

ASF subversion and git services commented on SOLR-4327:
---

Commit 1531598 from [~markrmil...@gmail.com] in branch 
'dev/branches/lucene_solr_4_5'
[ https://svn.apache.org/r1531598 ]

SOLR-4327: HttpSolrServer can leak connections on errors.

 SolrJ code review indicates potential for leaked HttpClient connections
 ---

 Key: SOLR-4327
 URL: https://issues.apache.org/jira/browse/SOLR-4327
 Project: Solr
  Issue Type: Bug
Affects Versions: 4.0
Reporter: Karl Wright
Assignee: Mark Miller
 Fix For: 4.5.1, 4.6, 5.0

 Attachments: SOLR-4327.patch, SOLR-4327.patch


 The SolrJ HttpSolrServer implementation does not seem to handle errors 
 properly and seems capable of leaking HttpClient connections.  See the 
 request() method in org.apache.solr.client.solrj.impl.HttpSolrServer.  The 
 issue is that exceptions thrown from within this method do not necessarily 
 consume the stream when an exception is thrown.  There is a try/finally block 
 which reads (in part):
 {code}
 } finally {
   if (respBody != null  processor!=null) {
 try {
   respBody.close();
 } catch (Throwable t) {} // ignore
   }
 }
 {code}
 But, in order to always guarantee consumption of the stream, it should 
 include:
 {code}
 method.abort();
 {code}



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!

Sigh, I didn't try the master seed, and no, I have no browser window open.

Maybe we can get the master seed included in a single test failure snippet?

Mike McCandless

http://blog.mikemccandless.com


On Sat, Oct 12, 2013 at 5:28 PM, Robert Muir rcm...@gmail.com wrote:
 Just the seed? or the master seed. if its a jvm bug we need the latter.

 flonkings already discarded the console log so we lost that, unless
 you still have it open in a browser or something?

 On Sat, Oct 12, 2013 at 4:39 PM, Michael McCandless
 luc...@mikemccandless.com wrote:
 Can anyone reproduce this failure?

 I tried beasting with 1.7.0_05 but no fails ...

 Mike McCandless

 http://blog.mikemccandless.com


 On Sat, Oct 12, 2013 at 9:11 AM,  buil...@flonkings.com wrote:
 Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63029/

 1 tests failed.
 REGRESSION:  
 org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting

 Error Message:


 Stack Trace:
 java.lang.NullPointerException
 at 
 org.apache.lucene.index.SnapshotDeletionPolicy.release(SnapshotDeletionPolicy.java:99)
 at 
 org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting(TestSnapshotDeletionPolicy.java:313)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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 
 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

[jira] [Commented] (LUCENE-5189) Numeric DocValues Updates

2013-10-12 Thread Michael McCandless (JIRA)


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

Michael McCandless commented on LUCENE-5189:


The test case changes look good!

This confused me:

{code}
+} else if (!fieldUpdate || random().nextBoolean()) { // sometimes 
do both deletes and updates
{code}

Shouldn't that just be its own if (not else if)?  Otherwise I think the comment 
is wrong ...

Also I think this:

{code}
+  if (liveDocs != null  liveDocs.get(i)) {
{code}

should be:

{code}
+  if (liveDocs == null || livedocs.get(i)) {
{code}

?

That's a great catch on forceMerge carrying the wrapped IOExc forward.  Why is 
jenkins not hitting this already...?

 Numeric DocValues Updates
 -

 Key: LUCENE-5189
 URL: https://issues.apache.org/jira/browse/LUCENE-5189
 Project: Lucene - Core
  Issue Type: New Feature
  Components: core/index
Reporter: Shai Erera
Assignee: Shai Erera
 Attachments: LUCENE-5189-4x.patch, LUCENE-5189-no-lost-updates.patch, 
 LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, 
 LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, 
 LUCENE-5189.patch, LUCENE-5189.patch, LUCENE-5189.patch, 
 LUCENE-5189_process_events.patch, LUCENE-5189_process_events.patch, 
 LUCENE-5189-updates-order.patch, LUCENE-5189-updates-order.patch


 In LUCENE-4258 we started to work on incremental field updates, however the 
 amount of changes are immense and hard to follow/consume. The reason is that 
 we targeted postings, stored fields, DV etc., all from the get go.
 I'd like to start afresh here, with numeric-dv-field updates only. There are 
 a couple of reasons to that:
 * NumericDV fields should be easier to update, if e.g. we write all the 
 values of all the documents in a segment for the updated field (similar to 
 how livedocs work, and previously norms).
 * It's a fairly contained issue, attempting to handle just one data type to 
 update, yet requires many changes to core code which will also be useful for 
 updating other data types.
 * It has value in and on itself, and we don't need to allow updating all the 
 data types in Lucene at once ... we can do that gradually.
 I have some working patch already which I'll upload next, explaining the 
 changes.



--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

Re: [JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 63029 - Failure!

2013-10-12 Thread Robert Muir

Or just configure flonkings to hold the logs longer. I know the
defaults are bad for this: but you can change it to keep them for e.g.
3 days or something so that the disk space usage is constant.

On Sat, Oct 12, 2013 at 6:50 PM, Michael McCandless
luc...@mikemccandless.com wrote:
 Sigh, I didn't try the master seed, and no, I have no browser window open.

 Maybe we can get the master seed included in a single test failure snippet?

 Mike McCandless

 http://blog.mikemccandless.com


 On Sat, Oct 12, 2013 at 5:28 PM, Robert Muir rcm...@gmail.com wrote:
 Just the seed? or the master seed. if its a jvm bug we need the latter.

 flonkings already discarded the console log so we lost that, unless
 you still have it open in a browser or something?

 On Sat, Oct 12, 2013 at 4:39 PM, Michael McCandless
 luc...@mikemccandless.com wrote:
 Can anyone reproduce this failure?

 I tried beasting with 1.7.0_05 but no fails ...

 Mike McCandless

 http://blog.mikemccandless.com


 On Sat, Oct 12, 2013 at 9:11 AM,  buil...@flonkings.com wrote:
 Build: 
 builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/63029/

 1 tests failed.
 REGRESSION:  
 org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting

 Error Message:


 Stack Trace:
 java.lang.NullPointerException
 at 
 org.apache.lucene.index.SnapshotDeletionPolicy.release(SnapshotDeletionPolicy.java:99)
 at 
 org.apache.lucene.index.TestSnapshotDeletionPolicy.testMultiThreadedSnapshotting(TestSnapshotDeletionPolicy.java:313)
 at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
 at 
 sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
 at 
 sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
 at java.lang.reflect.Method.invoke(Method.java:601)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
 at 
 com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
 at 
 org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
 at 
 org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
 at 
 org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java: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 
 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

[jira] [Closed] (SOLR-5339) solr-core-4.4's ip is not right when the os is centos 5.6 sometimes

2013-10-12 Thread Shawn Heisey (JIRA)

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

Shawn Heisey closed SOLR-5339.
--

Resolution: Invalid

You can manually specify what hostname or address will go into the cloud
configuration with by specifying instance parameters in solr.xml.

http://wiki.apache.org/solr/SolrCloud#SolrCloud_Instance_Params

If the wrong address is being detected, then it is likely that your operating
configuration isn't set up according to your expectactions. For a linux
machine, the best config is usually as described below, assuming that
myhost.example.com is the fully qualified name for your host:

* The actual hostname of the machine should be myhost - the short name. On
CentOS, this is defined in /etc/sysconfig/network.
* In /etc/hosts, only one entry should have the machine's actual hostname on
it, and it should look like the following:

192.168.10.54myhost.example.com myhost

This should ensure that when the local IP address is looked up, it will use
that entry in /etc/hosts. When you ask for the hostname, you will get
'myhost'. and when you ask for the fully qualified hostname, you will get
'myhost.example.com'.

I can't guarantee that the configuration I have described will work for every
situation, but it should ensure that Solr detects correctly.

solr-core-4.4's ip is not right when the os is centos 5.6 sometimes

Key: SOLR-5339
URL: https://issues.apache.org/jira/browse/SOLR-5339
Project: Solr
Issue Type: Bug
Components: contrib - Clustering
Affects Versions: 4.4
Environment: centos 5.6
Reporter: dejie Chang
Priority: Critical

when I install the solr-cloud on the centos5.6 . it is strange that sometimes
,the ip is not correct which is displayed on the
http://192.168.10.54:8081/solr/#/~cloud , it is 202.106.199.36,but my actual
is 192.168.10.54. but on the windows it is right. and i found it is because
of hostaddress = InetAddress.getLocalHost().getHostAddress(); in
ZkController.java . sometimes the method which get ip is not correct .we
should not trust . so i think in linux we should not use this method

--
This message was sent by Atlassian JIRA
(v6.1#6144)

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

[jira] [Resolved] (SOLR-4327) SolrJ code review indicates potential for leaked HttpClient connections