[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b123) - Build # 9152 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9152/ Java: 32bit/jdk1.8.0-ea-b123 -server -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 1221 lines...] [junit4] JVM J1: stdout was not empty, see: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp/junit4-J1-20140119_094737_117.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=0x, pid=15321, tid=3865049920 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (8.0-b123) (build 1.8.0-ea-b123) [junit4] # Java VM: Java HotSpot(TM) Server VM (25.0-b65 mixed mode linux-x86 ) [junit4] # Problematic frame: [junit4] # C 0x [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/core/test/J1/hs_err_pid15321.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 400 lines...] [junit4] ERROR: JVM J1 ended with an exception, command line: /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b123/jre/bin/java -server -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/heapdumps -Dtests.prefix=tests -Dtests.seed=CE0AE99C39EB2340 -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/core/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 -Djdk.map.althashing.threshold=0 -Dtests.disableHdfs=true -Dfile.encoding=UTF-8 -classpath
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b123) - Build # 9152 - Failure!
This is a new one. Policeman Jenkins Server jenk...@thetaphi.de schrieb: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9152/ Java: 32bit/jdk1.8.0-ea-b123 -server -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 1221 lines...] [junit4] JVM J1: stdout was not empty, see: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp/junit4-J1-20140119_094737_117.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=0x, pid=15321, tid=3865049920 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (8.0-b123) (build 1.8.0-ea-b123) [junit4] # Java VM: Java HotSpot(TM) Server VM (25.0-b65 mixed mode linux-x86 ) [junit4] # Problematic frame: [junit4] # C 0x [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/core/test/J1/hs_err_pid15321.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 400 lines...] [junit4] ERROR: JVM J1 ended with an exception, command line: /var/lib/jenkins/tools/java/32bit/jdk1.8.0-ea-b123/jre/bin/java -server -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/heapdumps -Dtests.prefix=tests -Dtests.seed=CE0AE99C39EB2340 -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/core/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 -Djdk.map.althashing.threshold=0 -Dtests.disableHdfs=true -Dfile.encoding=UTF-8 -classpath /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/codecs/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/test-framework/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/junit-4.10.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.13.jar:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/classes/java:/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/classes/test:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/ivy-2.3.0.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jai.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-swing.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-oro.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ ant-jmf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-javamail.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-resolver.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-testutil.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-logging.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-log4j.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-junit.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jsch.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-commons-net.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-apache-bsf.jar:/var/lib/jenkins/tools/hudson.tasks.Ant_AntInstallation/ANT_1.8.2/lib/ant-jdepend.jar:/var/lib/
RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b123) - Build # 9152 - Failure!
Hi all, hi Rory, New bug (not reproduceable) in JDK 8 b123, 32 bits: This one happened in the GC thread (ConcMarkSweep GC). All other threads are “blocked”, except the VM itself and the GCTaskThread, which segfaulted. So it seemed to happen on a full stop-the-world GC run (otherwise Java threads would still run while crashing). As always for GC failures, impossible to reproduce. Uwe --- T H R E A D --- Current thread (0xf6619000): GCTaskThread [stack: 0xe657f000,0xe660] [id=15351] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x Registers: EAX=0xce4e92fb, EBX=0xc70ce1c0, ECX=0x, EDX=0xc70ce1b0 ESP=0xe65fedcc, EBP=0xe65fee08, ESI=0xe574c484, EDI=0x0001 EIP=0x, EFLAGS=0x00010246, CR2=0x Top of Stack: (sp=0xe65fedcc) 0xe65fedcc: f6e9f7bb c70ce1b0 c70ce1c0 0001 0xe65feddc: 0001 f6619000 0004 0001 0xe65fedec: 00228100 0002 fff8 e574c4f4 0xe65fedfc: f661d1d8 f661d1d8 00028230 e65fee38 0xe65fee0c: f6ea091f c4cacff0 e56abc28 c14d8e60 0xe65fee1c: 000281fe 00028230 fffe fff8 0xe65fee2c: f661d1d8 c14d8e34 000281fe e65fee88 0xe65fee3c: f6ed2eb2 e56abc28 c14d8e60 000281fe Instructions: (pc=0x) 0xffe0: Register to memory mapping: EAX= [error occurred during error reporting (printing register info), id 0xb] Stack: [0xe657f000,0xe660], sp=0xe65fedcc, free space=511k --- P R O C E S S --- Java Threads: ( = current thread ) 0xc3388800 JavaThread TEST-TestPagedBytes.testDataInputOutput-seed#[CE0AE99C39EB2340] [_thread_blocked, id=19524, stack(0xc512e000,0xc517f000)] 0xc3dd5800 JavaThread SUITE-TestPagedBytes-seed#[CE0AE99C39EB2340] [_thread_blocked, id=19523, stack(0xc480f000,0xc486)] 0xc4764c00 JavaThread Service Thread daemon [_thread_blocked, id=15377, stack(0xe632e000,0xe637f000)] 0xc4751400 JavaThread C1 CompilerThread3 daemon [_thread_blocked, id=15371, stack(0xc3f73000,0xc3ff4000)] 0xc474fc00 JavaThread C2 CompilerThread2 daemon [_thread_blocked, id=15369, stack(0xc3ff4000,0xc4075000)] 0xc474e400 JavaThread C2 CompilerThread1 daemon [_thread_blocked, id=15367, stack(0xc4075000,0xc40f6000)] 0xc474c800 JavaThread C2 CompilerThread0 daemon [_thread_blocked, id=15365, stack(0xc40f6000,0xc4177000)] 0xc474b000 JavaThread Signal Dispatcher daemon [_thread_blocked, id=15364, stack(0xe652e000,0xe657f000)] 0xc4749c00 JavaThread Surrogate Locker Thread (Concurrent GC) daemon [_thread_blocked, id=15363, stack(0xe672e000,0xe677f000)] 0xc4713c00 JavaThread Finalizer daemon [_thread_blocked, id=15361, stack(0xe692e000,0xe697f000)] 0xc4712400 JavaThread Reference Handler daemon [_thread_blocked, id=15360, stack(0xe6b2e000,0xe6b7f000)] 0xf660a800 JavaThread main [_thread_blocked, id=15326, stack(0xf6749000,0xf679a000)] Other Threads: 0xc470e000 VMThread [stack: 0xc486,0xc48e1000] [id=15357] 0xc4766c00 WatcherThread [stack: 0xc3ef2000,0xc3f73000] [id=15378] =0xf6619000 (exited) GCTaskThread [stack: 0xe657f000,0xe660] [id=15351] VM state:at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) [0xf6608060] Threads_lock - owner thread: 0xc470e000 [0xf66084d8] Heap_lock - owner thread: 0xc3388800 Heap: par new generation total 136832K, used 117967K [0xc620, 0xcf67, 0xd0ca) eden space 121664K, 96% used [0xc620, 0xcd4e8be0, 0xcd8d) from space 15168K, 1% used [0xce7a, 0xce7eb110, 0xcf67) to space 15168K, 83% used [0xcd8d, 0xce53be30, 0xce7a) concurrent mark-sweep generation total 346844K, used 312517K [0xd0ca, 0xe5f57000, 0xe620) Metaspace used 15128K, capacity 15218K, committed 15256K, reserved 15664K - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Uwe Schindler [mailto:u...@thetaphi.de] Sent: Sunday, January 19, 2014 11:50 AM To: dev@lucene.apache.org Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b123) - Build # 9152 - Failure! This is a new one. Policeman Jenkins Server jenk...@thetaphi.de schrieb: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9152/ Java: 32bit/jdk1.8.0-ea-b123 -server -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 1221 lines...] [junit4] JVM J1: stdout was not empty, see: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/temp/junit4-J1-20140119_094737_117.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=0x, pid=15321, tid=3865049920 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (8.0-b123) (build
RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b123) - Build # 9152 - Failure!
As always, h_err is here: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9152/artifact/lucene/build/core/test/J1/hs_err_pid15321.log Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Uwe Schindler [mailto:u...@thetaphi.de] Sent: Sunday, January 19, 2014 1:10 PM To: 'dev@lucene.apache.org' Cc: rory.odonn...@oracle.com Subject: RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b123) - Build # 9152 - Failure! Hi all, hi Rory, New bug (not reproduceable) in JDK 8 b123, 32 bits: This one happened in the GC thread (ConcMarkSweep GC). All other threads are “blocked”, except the VM itself and the GCTaskThread, which segfaulted. So it seemed to happen on a full stop-the-world GC run (otherwise Java threads would still run while crashing). As always for GC failures, impossible to reproduce. Uwe --- T H R E A D --- Current thread (0xf6619000): GCTaskThread [stack: 0xe657f000,0xe660] [id=15351] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x Registers: EAX=0xce4e92fb, EBX=0xc70ce1c0, ECX=0x, EDX=0xc70ce1b0 ESP=0xe65fedcc, EBP=0xe65fee08, ESI=0xe574c484, EDI=0x0001 EIP=0x, EFLAGS=0x00010246, CR2=0x Top of Stack: (sp=0xe65fedcc) 0xe65fedcc: f6e9f7bb c70ce1b0 c70ce1c0 0001 0xe65feddc: 0001 f6619000 0004 0001 0xe65fedec: 00228100 0002 fff8 e574c4f4 0xe65fedfc: f661d1d8 f661d1d8 00028230 e65fee38 0xe65fee0c: f6ea091f c4cacff0 e56abc28 c14d8e60 0xe65fee1c: 000281fe 00028230 fffe fff8 0xe65fee2c: f661d1d8 c14d8e34 000281fe e65fee88 0xe65fee3c: f6ed2eb2 e56abc28 c14d8e60 000281fe Instructions: (pc=0x) 0xffe0: Register to memory mapping: EAX= [error occurred during error reporting (printing register info), id 0xb] Stack: [0xe657f000,0xe660], sp=0xe65fedcc, free space=511k --- P R O C E S S --- Java Threads: ( = current thread ) 0xc3388800 JavaThread TEST-TestPagedBytes.testDataInputOutput-seed#[CE0AE99C39EB2340] [_thread_blocked, id=19524, stack(0xc512e000,0xc517f000)] 0xc3dd5800 JavaThread SUITE-TestPagedBytes-seed#[CE0AE99C39EB2340] [_thread_blocked, id=19523, stack(0xc480f000,0xc486)] 0xc4764c00 JavaThread Service Thread daemon [_thread_blocked, id=15377, stack(0xe632e000,0xe637f000)] 0xc4751400 JavaThread C1 CompilerThread3 daemon [_thread_blocked, id=15371, stack(0xc3f73000,0xc3ff4000)] 0xc474fc00 JavaThread C2 CompilerThread2 daemon [_thread_blocked, id=15369, stack(0xc3ff4000,0xc4075000)] 0xc474e400 JavaThread C2 CompilerThread1 daemon [_thread_blocked, id=15367, stack(0xc4075000,0xc40f6000)] 0xc474c800 JavaThread C2 CompilerThread0 daemon [_thread_blocked, id=15365, stack(0xc40f6000,0xc4177000)] 0xc474b000 JavaThread Signal Dispatcher daemon [_thread_blocked, id=15364, stack(0xe652e000,0xe657f000)] 0xc4749c00 JavaThread Surrogate Locker Thread (Concurrent GC) daemon [_thread_blocked, id=15363, stack(0xe672e000,0xe677f000)] 0xc4713c00 JavaThread Finalizer daemon [_thread_blocked, id=15361, stack(0xe692e000,0xe697f000)] 0xc4712400 JavaThread Reference Handler daemon [_thread_blocked, id=15360, stack(0xe6b2e000,0xe6b7f000)] 0xf660a800 JavaThread main [_thread_blocked, id=15326, stack(0xf6749000,0xf679a000)] Other Threads: 0xc470e000 VMThread [stack: 0xc486,0xc48e1000] [id=15357] 0xc4766c00 WatcherThread [stack: 0xc3ef2000,0xc3f73000] [id=15378] =0xf6619000 (exited) GCTaskThread [stack: 0xe657f000,0xe660] [id=15351] VM state:at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) [0xf6608060] Threads_lock - owner thread: 0xc470e000 [0xf66084d8] Heap_lock - owner thread: 0xc3388800 Heap: par new generation total 136832K, used 117967K [0xc620, 0xcf67, 0xd0ca) eden space 121664K, 96% used [0xc620, 0xcd4e8be0, 0xcd8d) from space 15168K, 1% used [0xce7a, 0xce7eb110, 0xcf67) to space 15168K, 83% used [0xcd8d, 0xce53be30, 0xce7a) concurrent mark-sweep generation total 346844K, used 312517K [0xd0ca, 0xe5f57000, 0xe620) Metaspace used 15128K, capacity 15218K, committed 15256K, reserved 15664K - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Uwe Schindler [mailto:u...@thetaphi.de] Sent: Sunday, January 19, 2014 11:50 AM To: dev@lucene.apache.org Subject: Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b123) - Build # 9152 - Failure! This is a new one. Policeman Jenkins Server jenk...@thetaphi.de schrieb: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9152/ Java: 32bit/jdk1.8.0-ea-b123 -server -XX:+UseConcMarkSweepGC
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #1083: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/1083/ 2 tests failed. REGRESSION: org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testDistribSearch Error Message: null Stack Trace: java.lang.AssertionError: null at __randomizedtesting.SeedInfo.seed([F96643ADFB7282F4:7880CDB58C2DE2C8]:0) at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertFalse(Assert.java:68) at org.junit.Assert.assertFalse(Assert.java:79) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390) at org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203) REGRESSION: org.apache.solr.cloud.ShardSplitTest.testDistribSearch Error Message: Wrong doc count on shard1_1 expected:47 but was:30 Stack Trace: java.lang.AssertionError: Wrong doc count on shard1_1 expected:47 but was:30 at __randomizedtesting.SeedInfo.seed([1DEA7D5C1688A135:9C0CF34461D7C109]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.solr.cloud.ShardSplitTest.checkDocCountsAndShardStates(ShardSplitTest.java:478) at org.apache.solr.cloud.ShardSplitTest.splitByUniqueKeyTest(ShardSplitTest.java:249) at org.apache.solr.cloud.ShardSplitTest.doTest(ShardSplitTest.java:113) Build Log: [...truncated 52810 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:476: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/build.xml:176: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Maven-trunk/extra-targets.xml:77: Java returned: 1 Total time: 127 minutes 2 seconds Build step 'Invoke Ant' marked build as failure Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5526) Query parser extends standard cause NPE on Solr startup
[
https://issues.apache.org/jira/browse/SOLR-5526?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Vitaliy Zhovtyuk updated SOLR-5526:
---
Attachment: NPE_load_trace
NPE stacktrace during solr load
Query parser extends standard cause NPE on Solr startup
---
Key: SOLR-5526
URL: https://issues.apache.org/jira/browse/SOLR-5526
Project: Solr
Issue Type: Bug
Components: query parsers
Affects Versions: 4.5.1, 4.6, 5.0
Environment: Linux, Java 1.7.0_45
Reporter: Nikolay Khitrin
Priority: Blocker
Attachments: NPE_load_trace, SOLR-5526-final-names.patch,
SOLR-5526.patch
Adding any custom query parser extending standard one with non-final field
{{NAME}} lead to messy {{NullPointerException}} during Solr startup.
Definition of standard parsers is located in
{{QParserPlugin.standardPlugins}} static array. The array contains names from
static {{NAME}} fields and classes for each plugin.
But all of listed parsers are derived from {{QParserPlugin}}, so we have
circular dependency of static fields.
Normally, class loader start initializing {{QParserPlugin}} before all listed
plugins in {{SolrCore.initQParsers}}, and array elements referenced to
{{NAME}} plugins' fields are filled properly.
Custom parsers are instantiated before standard parsers. And when we subclass
plugin with non-final {{NAME}} field and add it to Solr via
{{solrconfig.xml}}, class loader start loading our class before
{{QParserPlugin}}. Because {{QParserPlugin}} is a superclass for plugin, it
must be initialized before subclasses, and static dereferencing cause null
elements in {{standardPlugins}} array because it filled before {{NAME}} field
of loading plugin's superclass.
How to reproduce:
# Checkout Solr (trunk or stable)
# Add the following line to solr/example/solr/collection1/conf/solrconfig.xml
{{queryParser name=fail class=solr.search.LuceneQParserPlugin/}}
# Call ant run-example in solr folder
Possible workarounds:
* dev-workaround: add {{int workaround =
QParserPlugin.standardPlugins.length;}} as a first line to
{{SolrCore.initQParsers}}
* user-workaround: add plugin with final {{NAME}} field (edismax) to
solrconfig.xml before subclasses of standard plugins.
{{queryParser name=workaround
class=solr.search.ExtendedDismaxQParserPlugin/}}
Possible fix:
Move {{standardPlugins}} to new final class to break circular dependency.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5376) Add a demo search server
[ https://issues.apache.org/jira/browse/LUCENE-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875921#comment-13875921 ] ASF subversion and git services commented on LUCENE-5376: - Commit 1559524 from [~mikemccand] in branch 'dev/branches/lucene5376' [ https://svn.apache.org/r1559524 ] LUCENE-5376: cutover to analysis factories to create tokenizer and token filters; still need char filters whole analyzers Add a demo search server Key: LUCENE-5376 URL: https://issues.apache.org/jira/browse/LUCENE-5376 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: lucene-demo-server.tgz I think it'd be useful to have a demo search server for Lucene. Rather than being fully featured, like Solr, it would be minimal, just wrapping the existing Lucene modules to show how you can make use of these features in a server setting. The purpose is to demonstrate how one can build a minimal search server on top of APIs like SearchManager, SearcherLifetimeManager, etc. This is also useful for finding rough edges / issues in Lucene's APIs that make building a server unnecessarily hard. I don't think it should have back compatibility promises (except Lucene's index back compatibility), so it's free to improve as Lucene's APIs change. As a starting point, I'll post what I built for the eating your own dog food search app for Lucene's Solr's jira issues http://jirasearch.mikemccandless.com (blog: http://blog.mikemccandless.com/2013/05/eating-dog-food-with-lucene.html ). It uses Netty to expose basic indexing searching APIs via JSON, but it's very rough (lots nocommits). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5644) SplitShard does not handle not finding a shard leader well.
Mark Miller created SOLR-5644: - Summary: SplitShard does not handle not finding a shard leader well. Key: SOLR-5644 URL: https://issues.apache.org/jira/browse/SOLR-5644 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Priority: Minor Fix For: 5.0, 4.7 In OverseerCollectionProcessor: // find the leader for the shard Replica parentShardLeader = clusterState.getLeader(collectionName, slice); This returns null if there is no current leader and the following code does not deal with that case and instead NPE's. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b123) - Build # 9152 - Failure!
Hi Uwe, Can you get a bug logged , include that log etc. let me know the incident number and I will move it along. Should mention that unfortunately it's not reproducible! Thanks Rory On 19/01/2014 12:10, Uwe Schindler wrote: As always, h_err is here: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9152/artifact/lucene/build/core/test/J1/hs_err_pid15321.log Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de http://www.thetaphi.de/ eMail: u...@thetaphi.de *From:*Uwe Schindler [mailto:u...@thetaphi.de] *Sent:* Sunday, January 19, 2014 1:10 PM *To:* 'dev@lucene.apache.org' *Cc:* rory.odonn...@oracle.com *Subject:* RE: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b123) - Build # 9152 - Failure! Hi all, hi Rory, New bug (not reproduceable) in JDK 8 b123, 32 bits: This one happened in the GC thread (ConcMarkSweep GC). All other threads are “blocked”, except the VM itself and the GCTaskThread, which segfaulted. So it seemed to happen on a full stop-the-world GC run (otherwise Java threads would still run while crashing). As always for GC failures, impossible to reproduce. Uwe --- T H R E A D --- Current thread (0xf6619000): GCTaskThread [stack: 0xe657f000,0xe660] [id=15351] siginfo:si_signo=SIGSEGV: si_errno=0, si_code=1 (SEGV_MAPERR), si_addr=0x Registers: EAX=0xce4e92fb, EBX=0xc70ce1c0, ECX=0x, EDX=0xc70ce1b0 ESP=0xe65fedcc, EBP=0xe65fee08, ESI=0xe574c484, EDI=0x0001 EIP=0x, EFLAGS=0x00010246, CR2=0x Top of Stack: (sp=0xe65fedcc) 0xe65fedcc: f6e9f7bb c70ce1b0 c70ce1c0 0001 0xe65feddc: 0001 f6619000 0004 0001 0xe65fedec: 00228100 0002 fff8 e574c4f4 0xe65fedfc: f661d1d8 f661d1d8 00028230 e65fee38 0xe65fee0c: f6ea091f c4cacff0 e56abc28 c14d8e60 0xe65fee1c: 000281fe 00028230 fffe fff8 0xe65fee2c: f661d1d8 c14d8e34 000281fe e65fee88 0xe65fee3c: f6ed2eb2 e56abc28 c14d8e60 000281fe Instructions: (pc=0x) 0xffe0: Register to memory mapping: EAX= [error occurred during error reporting (printing register info), id 0xb] Stack: [0xe657f000,0xe660], sp=0xe65fedcc, free space=511k --- P R O C E S S --- Java Threads: ( = current thread ) 0xc3388800 JavaThread TEST-TestPagedBytes.testDataInputOutput-seed#[CE0AE99C39EB2340] [_thread_blocked, id=19524, stack(0xc512e000,0xc517f000)] 0xc3dd5800 JavaThread SUITE-TestPagedBytes-seed#[CE0AE99C39EB2340] [_thread_blocked, id=19523, stack(0xc480f000,0xc486)] 0xc4764c00 JavaThread Service Thread daemon [_thread_blocked, id=15377, stack(0xe632e000,0xe637f000)] 0xc4751400 JavaThread C1 CompilerThread3 daemon [_thread_blocked, id=15371, stack(0xc3f73000,0xc3ff4000)] 0xc474fc00 JavaThread C2 CompilerThread2 daemon [_thread_blocked, id=15369, stack(0xc3ff4000,0xc4075000)] 0xc474e400 JavaThread C2 CompilerThread1 daemon [_thread_blocked, id=15367, stack(0xc4075000,0xc40f6000)] 0xc474c800 JavaThread C2 CompilerThread0 daemon [_thread_blocked, id=15365, stack(0xc40f6000,0xc4177000)] 0xc474b000 JavaThread Signal Dispatcher daemon [_thread_blocked, id=15364, stack(0xe652e000,0xe657f000)] 0xc4749c00 JavaThread Surrogate Locker Thread (Concurrent GC) daemon [_thread_blocked, id=15363, stack(0xe672e000,0xe677f000)] 0xc4713c00 JavaThread Finalizer daemon [_thread_blocked, id=15361, stack(0xe692e000,0xe697f000)] 0xc4712400 JavaThread Reference Handler daemon [_thread_blocked, id=15360, stack(0xe6b2e000,0xe6b7f000)] 0xf660a800 JavaThread main [_thread_blocked, id=15326, stack(0xf6749000,0xf679a000)] Other Threads: 0xc470e000 VMThread [stack: 0xc486,0xc48e1000] [id=15357] 0xc4766c00 WatcherThread [stack: 0xc3ef2000,0xc3f73000] [id=15378] =0xf6619000 (exited) GCTaskThread [stack: 0xe657f000,0xe660] [id=15351] VM state:at safepoint (normal execution) VM Mutex/Monitor currently owned by a thread: ([mutex/lock_event]) [0xf6608060] Threads_lock - owner thread: 0xc470e000 [0xf66084d8] Heap_lock - owner thread: 0xc3388800 Heap: par new generation total 136832K, used 117967K [0xc620, 0xcf67, 0xd0ca) eden space 121664K, 96% used [0xc620, 0xcd4e8be0, 0xcd8d) from space 15168K, 1% used [0xce7a, 0xce7eb110, 0xcf67) to space 15168K, 83% used [0xcd8d, 0xce53be30, 0xce7a) concurrent mark-sweep generation total 346844K, used 312517K [0xd0ca, 0xe5f57000, 0xe620) Metaspace used 15128K, capacity 15218K, committed 15256K, reserved 15664K - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de http://www.thetaphi.de/ eMail: u...@thetaphi.de mailto:u...@thetaphi.de *From:*Uwe Schindler [mailto:u...@thetaphi.de] *Sent:* Sunday, January 19, 2014 11:50 AM *To:* dev@lucene.apache.org mailto:dev@lucene.apache.org *Subject:* Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b123)
[jira] [Commented] (LUCENE-5376) Add a demo search server
[ https://issues.apache.org/jira/browse/LUCENE-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875958#comment-13875958 ] ASF subversion and git services commented on LUCENE-5376: - Commit 1559542 from [~mikemccand] in branch 'dev/branches/lucene5376' [ https://svn.apache.org/r1559542 ] LUCENE-5376: always throw unchecked cause of the InvocationTargetException Add a demo search server Key: LUCENE-5376 URL: https://issues.apache.org/jira/browse/LUCENE-5376 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: lucene-demo-server.tgz I think it'd be useful to have a demo search server for Lucene. Rather than being fully featured, like Solr, it would be minimal, just wrapping the existing Lucene modules to show how you can make use of these features in a server setting. The purpose is to demonstrate how one can build a minimal search server on top of APIs like SearchManager, SearcherLifetimeManager, etc. This is also useful for finding rough edges / issues in Lucene's APIs that make building a server unnecessarily hard. I don't think it should have back compatibility promises (except Lucene's index back compatibility), so it's free to improve as Lucene's APIs change. As a starting point, I'll post what I built for the eating your own dog food search app for Lucene's Solr's jira issues http://jirasearch.mikemccandless.com (blog: http://blog.mikemccandless.com/2013/05/eating-dog-food-with-lucene.html ). It uses Netty to expose basic indexing searching APIs via JSON, but it's very rough (lots nocommits). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5645) A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore.
Mark Miller created SOLR-5645: - Summary: A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore. Key: SOLR-5645 URL: https://issues.apache.org/jira/browse/SOLR-5645 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 -- This message was sent by Atlassian JIRA (v6.1.5#6160) - 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 # 1213 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1213/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. REGRESSION: org.apache.solr.core.TestNonNRTOpen.testReaderIsNotNRT Error Message: expected:3 but was:2 Stack Trace: java.lang.AssertionError: expected:3 but was:2 at __randomizedtesting.SeedInfo.seed([DE4BF53143C82B79:6BCD94B6FC09998D]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.core.TestNonNRTOpen.assertNotNRT(TestNonNRTOpen.java:133) at org.apache.solr.core.TestNonNRTOpen.testReaderIsNotNRT(TestNonNRTOpen.java:94) 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:606) 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
[jira] [Commented] (SOLR-5645) A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore.
[ https://issues.apache.org/jira/browse/SOLR-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875994#comment-13875994 ] Mark Miller commented on SOLR-5645: --- I almost think we should re roll 4.6.1 for this... I think the issue was probably not so bad in 4.6, because pre SOLR-5615, we were not careful about not starting new leader elections while old ones existed. So reload might have had funky issues due to this in 4.6, but they were not so evident as you can now have due to not being able to find a leader on reload (as exposed by fails on jenkins test runs). A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore. Key: SOLR-5645 URL: https://issues.apache.org/jira/browse/SOLR-5645 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC1
Unfortunately, I think SOLR-5645 is probably worth a re spin. I think otherwise, collection reloads will be unstable vs 4.6. On Sat, Jan 18, 2014 at 10:29 AM, Sanne Grinovero sanne.grinov...@gmail.com wrote: +1 Run integration tests with: - Hibernate Search - Infinispan (indexing/searching entries with Lucene) - Infinispan (storing indexes from Lucene) All perfect, great job! (For long we've been stuck on Lucene 3.x but that's finally resolved) Sanne On 18 January 2014 01:51, Steve Rowe sar...@gmail.com wrote: +1 Smoke tester says: SUCCESS! [1:03:14.565590] Changes, docs and javadocs look good. Steve On Jan 17, 2014, at 9:13 AM, Mark Miller markrmil...@gmail.com wrote: Please vote to release the following artifacts: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1559132/ Here is my +1. -- - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Mark
[jira] [Updated] (SOLR-5645) A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore.
[ https://issues.apache.org/jira/browse/SOLR-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5645: -- Fix Version/s: 4.6.1 A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore. Key: SOLR-5645 URL: https://issues.apache.org/jira/browse/SOLR-5645 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7, 4.6.1 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1211/ -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5645) A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore.
[ https://issues.apache.org/jira/browse/SOLR-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5645: -- Description: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1211/ A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore. Key: SOLR-5645 URL: https://issues.apache.org/jira/browse/SOLR-5645 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7, 4.6.1 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1211/ -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1559318 - in /lucene/dev/branches/lucene_solr_4_6/lucene: ./ queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/ queryparser/src/test/org/apache/lucene/qu
On Jan 18, 2014, at 10:03 PM, Adriano Crestani adrianocrest...@gmail.com wrote: Thanks for letting me know. So it will be pushed automatically to 4.6.2, right?! Right. All we will need to do is change the CHANGES.txt. Right. Though it looks like we should re spin 4.6.1, in which case it will be included. - Mark On Sat, Jan 18, 2014 at 12:35 PM, Robert Muir rcm...@gmail.com wrote: FYI, I am not sure this commit made it in time for the current 4.6.1 release candidate being voted on. On Fri, Jan 17, 2014 at 9:36 PM, adrianocrest...@apache.org wrote: Author: adrianocrestani Date: Sat Jan 18 05:36:28 2014 New Revision: 1559318 URL: http://svn.apache.org/r1559318 Log: LUCENE-Flexible StandardQueryParser behaves differently than ClassicQueryParser (4.6 branch) Modified: lucene/dev/branches/lucene_solr_4_6/lucene/CHANGES.txt lucene/dev/branches/lucene_solr_4_6/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/AnalyzerQueryNodeProcessor.java lucene/dev/branches/lucene_solr_4_6/lucene/queryparser/src/test/org/apache/lucene/queryparser/util/QueryParserTestBase.java Modified: lucene/dev/branches/lucene_solr_4_6/lucene/CHANGES.txt URL: http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_6/lucene/CHANGES.txt?rev=1559318r1=1559317r2=1559318view=diff == --- lucene/dev/branches/lucene_solr_4_6/lucene/CHANGES.txt (original) +++ lucene/dev/branches/lucene_solr_4_6/lucene/CHANGES.txt Sat Jan 18 05:36:28 2014 @@ -22,6 +22,9 @@ Bug fixes * LUCENE-5394: Fix TokenSources.getTokenStream to return payloads if they were indexed with the term vectors. (Mike McCandless) + +* LUCENE-5344: Flexible StandardQueryParser behaves differently than + ClassicQueryParser. (Adriano Crestani) * LUCENE-5375: ToChildBlockJoinQuery works harder to detect mis-use, when the parent query incorrectly returns child documents, and throw @@ -139,7 +142,7 @@ Bug Fixes * LUCENE-5342: Fixed bulk-merge issue in CompressingStoredFieldsFormat which created corrupted segments when mixing chunk sizes. Lucene41StoredFieldsFormat is not impacted. (Adrien Grand, Robert Muir) - + API Changes * LUCENE-5222: Add SortField.needsScores(). Previously it was not possible Modified: lucene/dev/branches/lucene_solr_4_6/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/AnalyzerQueryNodeProcessor.java URL: http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_6/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/AnalyzerQueryNodeProcessor.java?rev=1559318r1=1559317r2=1559318view=diff == --- lucene/dev/branches/lucene_solr_4_6/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/AnalyzerQueryNodeProcessor.java (original) +++ lucene/dev/branches/lucene_solr_4_6/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/AnalyzerQueryNodeProcessor.java Sat Jan 18 05:36:28 2014 @@ -19,6 +19,7 @@ package org.apache.lucene.queryparser.fl import java.io.IOException; import java.util.ArrayList; +import java.util.Collections; import java.util.LinkedList; import java.util.List; @@ -27,23 +28,32 @@ import org.apache.lucene.analysis.Cachin import org.apache.lucene.analysis.TokenStream; import org.apache.lucene.analysis.tokenattributes.CharTermAttribute; import org.apache.lucene.analysis.tokenattributes.PositionIncrementAttribute; +import org.apache.lucene.index.Term; import org.apache.lucene.queryparser.flexible.core.QueryNodeException; import org.apache.lucene.queryparser.flexible.core.config.QueryConfigHandler; +import org.apache.lucene.queryparser.flexible.core.nodes.BooleanQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.FieldQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.FuzzyQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.GroupQueryNode; +import org.apache.lucene.queryparser.flexible.core.nodes.ModifierQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.NoTokenFoundQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.QueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.QuotedFieldQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.RangeQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.TextableQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.TokenizedPhraseQueryNode; +import org.apache.lucene.queryparser.flexible.core.nodes.ModifierQueryNode.Modifier; import org.apache.lucene.queryparser.flexible.core.processors.QueryNodeProcessorImpl; import
[jira] [Commented] (SOLR-5645) A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore.
[ https://issues.apache.org/jira/browse/SOLR-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13875998#comment-13875998 ] ASF subversion and git services commented on SOLR-5645: --- Commit 1559578 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1559578 ] SOLR-5645: A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore. A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore. Key: SOLR-5645 URL: https://issues.apache.org/jira/browse/SOLR-5645 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7, 4.6.1 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1211/ -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5645) A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore.
[ https://issues.apache.org/jira/browse/SOLR-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876001#comment-13876001 ] ASF subversion and git services commented on SOLR-5645: --- Commit 1559579 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1559579 ] SOLR-5645: A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore. A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore. Key: SOLR-5645 URL: https://issues.apache.org/jira/browse/SOLR-5645 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7, 4.6.1 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1211/ -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5645) A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore.
[ https://issues.apache.org/jira/browse/SOLR-5645?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876003#comment-13876003 ] ASF subversion and git services commented on SOLR-5645: --- Commit 1559581 from [~markrmil...@gmail.com] in branch 'dev/branches/lucene_solr_4_6' [ https://svn.apache.org/r1559581 ] SOLR-5645: A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore. A SolrCore reload via the CoreContainer will try and register in zk again with the new SolrCore. Key: SOLR-5645 URL: https://issues.apache.org/jira/browse/SOLR-5645 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7, 4.6.1 http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1211/ -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5636) SolrRequestParsers does some xpath lookups on every request.
[ https://issues.apache.org/jira/browse/SOLR-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5636: -- Fix Version/s: 4.6.1 This might as well go into a 4.6.1 respin. SolrRequestParsers does some xpath lookups on every request. Key: SOLR-5636 URL: https://issues.apache.org/jira/browse/SOLR-5636 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 5.0, 4.7, 4.6.1 Attachments: SOLR-5636.patch This seems a bit wasteful for one, but also, under heavy load, with lots of cores on a node, I've seen this xpath parsing randomly fail with weird nullpointer exceptions. Perhaps depends on the xml parser you end up using. Anyway, it's easy to work around and avoid the parsing everytime solrdispatchfilter is hit by just doing it up front once. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5636) SolrRequestParsers does some xpath lookups on every request.
[ https://issues.apache.org/jira/browse/SOLR-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876007#comment-13876007 ] ASF subversion and git services commented on SOLR-5636: --- Commit 1559582 from [~markrmil...@gmail.com] in branch 'dev/branches/lucene_solr_4_6' [ https://svn.apache.org/r1559582 ] SOLR-5636: SolrRequestParsers does some xpath lookups on every request, which can cause concurrency issues. SolrRequestParsers does some xpath lookups on every request. Key: SOLR-5636 URL: https://issues.apache.org/jira/browse/SOLR-5636 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 5.0, 4.7, 4.6.1 Attachments: SOLR-5636.patch This seems a bit wasteful for one, but also, under heavy load, with lots of cores on a node, I've seen this xpath parsing randomly fail with weird nullpointer exceptions. Perhaps depends on the xml parser you end up using. Anyway, it's easy to work around and avoid the parsing everytime solrdispatchfilter is hit by just doing it up front once. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5636) SolrRequestParsers does some xpath lookups on every request.
[ https://issues.apache.org/jira/browse/SOLR-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876008#comment-13876008 ] ASF subversion and git services commented on SOLR-5636: --- Commit 1559583 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1559583 ] SOLR-5636: Move CHANGES entry to 4.6 branch SolrRequestParsers does some xpath lookups on every request. Key: SOLR-5636 URL: https://issues.apache.org/jira/browse/SOLR-5636 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 5.0, 4.7, 4.6.1 Attachments: SOLR-5636.patch This seems a bit wasteful for one, but also, under heavy load, with lots of cores on a node, I've seen this xpath parsing randomly fail with weird nullpointer exceptions. Perhaps depends on the xml parser you end up using. Anyway, it's easy to work around and avoid the parsing everytime solrdispatchfilter is hit by just doing it up front once. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5636) SolrRequestParsers does some xpath lookups on every request.
[ https://issues.apache.org/jira/browse/SOLR-5636?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876009#comment-13876009 ] ASF subversion and git services commented on SOLR-5636: --- Commit 1559584 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1559584 ] SOLR-5636: Move CHANGES entry to 4.6 branch SolrRequestParsers does some xpath lookups on every request. Key: SOLR-5636 URL: https://issues.apache.org/jira/browse/SOLR-5636 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Priority: Minor Fix For: 5.0, 4.7, 4.6.1 Attachments: SOLR-5636.patch This seems a bit wasteful for one, but also, under heavy load, with lots of cores on a node, I've seen this xpath parsing randomly fail with weird nullpointer exceptions. Perhaps depends on the xml parser you end up using. Anyway, it's easy to work around and avoid the parsing everytime solrdispatchfilter is hit by just doing it up front once. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1559318 - in /lucene/dev/branches/lucene_solr_4_6/lucene: ./ queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/ queryparser/src/test/org/apache/lucene/qu
Nice. Thanks Mark ;) On Sun, Jan 19, 2014 at 3:08 PM, Mark Miller markrmil...@gmail.com wrote: On Jan 18, 2014, at 10:03 PM, Adriano Crestani adrianocrest...@gmail.com wrote: Thanks for letting me know. So it will be pushed automatically to 4.6.2, right?! Right. All we will need to do is change the CHANGES.txt. Right. Though it looks like we should re spin 4.6.1, in which case it will be included. - Mark On Sat, Jan 18, 2014 at 12:35 PM, Robert Muir rcm...@gmail.com wrote: FYI, I am not sure this commit made it in time for the current 4.6.1 release candidate being voted on. On Fri, Jan 17, 2014 at 9:36 PM, adrianocrest...@apache.org wrote: Author: adrianocrestani Date: Sat Jan 18 05:36:28 2014 New Revision: 1559318 URL: http://svn.apache.org/r1559318 Log: LUCENE-Flexible StandardQueryParser behaves differently than ClassicQueryParser (4.6 branch) Modified: lucene/dev/branches/lucene_solr_4_6/lucene/CHANGES.txt lucene/dev/branches/lucene_solr_4_6/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/AnalyzerQueryNodeProcessor.java lucene/dev/branches/lucene_solr_4_6/lucene/queryparser/src/test/org/apache/lucene/queryparser/util/QueryParserTestBase.java Modified: lucene/dev/branches/lucene_solr_4_6/lucene/CHANGES.txt URL: http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_6/lucene/CHANGES.txt?rev=1559318r1=1559317r2=1559318view=diff == --- lucene/dev/branches/lucene_solr_4_6/lucene/CHANGES.txt (original) +++ lucene/dev/branches/lucene_solr_4_6/lucene/CHANGES.txt Sat Jan 18 05:36:28 2014 @@ -22,6 +22,9 @@ Bug fixes * LUCENE-5394: Fix TokenSources.getTokenStream to return payloads if they were indexed with the term vectors. (Mike McCandless) + +* LUCENE-5344: Flexible StandardQueryParser behaves differently than + ClassicQueryParser. (Adriano Crestani) * LUCENE-5375: ToChildBlockJoinQuery works harder to detect mis-use, when the parent query incorrectly returns child documents, and throw @@ -139,7 +142,7 @@ Bug Fixes * LUCENE-5342: Fixed bulk-merge issue in CompressingStoredFieldsFormat which created corrupted segments when mixing chunk sizes. Lucene41StoredFieldsFormat is not impacted. (Adrien Grand, Robert Muir) - + API Changes * LUCENE-5222: Add SortField.needsScores(). Previously it was not possible Modified: lucene/dev/branches/lucene_solr_4_6/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/AnalyzerQueryNodeProcessor.java URL: http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_6/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/AnalyzerQueryNodeProcessor.java?rev=1559318r1=1559317r2=1559318view=diff == --- lucene/dev/branches/lucene_solr_4_6/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/AnalyzerQueryNodeProcessor.java (original) +++ lucene/dev/branches/lucene_solr_4_6/lucene/queryparser/src/java/org/apache/lucene/queryparser/flexible/standard/processors/AnalyzerQueryNodeProcessor.java Sat Jan 18 05:36:28 2014 @@ -19,6 +19,7 @@ package org.apache.lucene.queryparser.fl import java.io.IOException; import java.util.ArrayList; +import java.util.Collections; import java.util.LinkedList; import java.util.List; @@ -27,23 +28,32 @@ import org.apache.lucene.analysis.Cachin import org.apache.lucene.analysis.TokenStream; import org.apache.lucene.analysis.tokenattributes.CharTermAttribute; import org.apache.lucene.analysis.tokenattributes.PositionIncrementAttribute; +import org.apache.lucene.index.Term; import org.apache.lucene.queryparser.flexible.core.QueryNodeException; import org.apache.lucene.queryparser.flexible.core.config.QueryConfigHandler; +import org.apache.lucene.queryparser.flexible.core.nodes.BooleanQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.FieldQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.FuzzyQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.GroupQueryNode; +import org.apache.lucene.queryparser.flexible.core.nodes.ModifierQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.NoTokenFoundQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.QueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.QuotedFieldQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.RangeQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.TextableQueryNode; import org.apache.lucene.queryparser.flexible.core.nodes.TokenizedPhraseQueryNode; +import org.apache.lucene.queryparser.flexible.core.nodes.ModifierQueryNode.Modifier; import
[jira] [Commented] (SOLR-5577) indexing delay due to zookeeper election
[
https://issues.apache.org/jira/browse/SOLR-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876013#comment-13876013
]
ASF subversion and git services commented on SOLR-5577:
---
Commit 1559587 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1559587 ]
SOLR-5577: Harden leaking Timer thread.
indexing delay due to zookeeper election
Key: SOLR-5577
URL: https://issues.apache.org/jira/browse/SOLR-5577
Project: Solr
Issue Type: Bug
Components: SolrCloud
Reporter: Christine Poerschke
Assignee: Mark Miller
Fix For: 5.0, 4.7, 4.6.1
Attachments: SOLR-5577.patch
The behaviour we observed was that a zookeeper election took about 2s plus
1.5s for reading the zoo_data snapshot. During this time solr tried to
establish connections to any zookeeper in the ensemble but only succeeded
once a leader was elected *and* that leader was done reading the snapshot.
Solr document updates were slowed down during this time window.
Is this expected to happen during and shortly after elections, that is
zookeeper closing existing connections, rejecting new connections and thus
stalling solr updates?
Other than avoiding zookeeper elections, are there ways of reducing their
impact on solr?
+zookeeper log extract+
{noformat}
08:18:54,968 [QuorumCnxManager.java:762] Connection broken for id ...
08:18:56,916 [Leader.java:345] LEADING - LEADER ELECTION TOOK - 1941
08:18:56,918 [FileSnap.java:83] Reading snapshot ...
...
08:18:57,010 [NIOServerCnxnFactory.java:197] Accepted socket connection from
...
08:18:57,010 [NIOServerCnxn.java:354] Exception causing close of session 0x0
due to java.io.IOException: ZooKeeperServer not running
08:18:57,010 [NIOServerCnxn.java:1001] Closed socket connection for client
... (no session established for client)
...
08:18:58,496 [FileTxnSnapLog.java:240] Snapshotting: ... to ...
{noformat}
+solr log extract+
{noformat}
08:18:54,968 [ClientCnxn.java:1085] Unable to read additional data from
server sessionid ... likely server has closed socket, closing socket
connection and attempting reconnect
08:18:55,068 [ConnectionManager.java:72] Watcher
org.apache.solr.common.cloud.ConnectionManager@... name:ZooKeeperConnection
Watcher:host1:port1,host2:port2,host3:port3,... got event WatchedEvent
state:Disconnected type:None path:null path:null type:None
08:18:55,068 [ConnectionManager.java:132] zkClient has disconnected
...
08:18:55,961 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:55,961 [ClientCnxn.java:849] Socket connection established to ...
08:18:55,962 [ClientCnxn.java:1085] Unable to read additional data from
server sessionid ... likely server has closed socket, closing socket
connection and attempting reconnect
...
08:18:56,714 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:56,715 [ClientCnxn.java:849] Socket connection established to ...
08:18:56,715 [ClientCnxn.java:1085] Unable to read additional data from ...
...
08:18:57,640 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:57,641 [ClientCnxn.java:849] Socket connection established to ...
08:18:57,641 [ClientCnxn.java:1085] Unable to read additional data from ...
...
08:18:58,352 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:58,353 [ClientCnxn.java:849] Socket connection established to ...
08:18:58,353 [ClientCnxn.java:1085] Unable to read additional data from ...
...
08:18:58,749 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:58,749 [ClientCnxn.java:849] Socket connection established to ...
08:18:58,751 [ClientCnxn.java:1207] Session establishment complete on server
... sessionid = ..., negotiated timeout = ...
08:18:58,751 ... [ConnectionManager.java:72] Watcher
org.apache.solr.common.cloud.ConnectionManager@... name:ZooKeeperConnection
Watcher:host1:port1,host2:port2,host3:port3,... got event WatchedEvent
state:SyncConnected type:None path:null path:null type:None
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5577) indexing delay due to zookeeper election
[
https://issues.apache.org/jira/browse/SOLR-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876014#comment-13876014
]
ASF subversion and git services commented on SOLR-5577:
---
Commit 1559588 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1559588 ]
SOLR-5577: Harden leaking Timer thread.
indexing delay due to zookeeper election
Key: SOLR-5577
URL: https://issues.apache.org/jira/browse/SOLR-5577
Project: Solr
Issue Type: Bug
Components: SolrCloud
Reporter: Christine Poerschke
Assignee: Mark Miller
Fix For: 5.0, 4.7, 4.6.1
Attachments: SOLR-5577.patch
The behaviour we observed was that a zookeeper election took about 2s plus
1.5s for reading the zoo_data snapshot. During this time solr tried to
establish connections to any zookeeper in the ensemble but only succeeded
once a leader was elected *and* that leader was done reading the snapshot.
Solr document updates were slowed down during this time window.
Is this expected to happen during and shortly after elections, that is
zookeeper closing existing connections, rejecting new connections and thus
stalling solr updates?
Other than avoiding zookeeper elections, are there ways of reducing their
impact on solr?
+zookeeper log extract+
{noformat}
08:18:54,968 [QuorumCnxManager.java:762] Connection broken for id ...
08:18:56,916 [Leader.java:345] LEADING - LEADER ELECTION TOOK - 1941
08:18:56,918 [FileSnap.java:83] Reading snapshot ...
...
08:18:57,010 [NIOServerCnxnFactory.java:197] Accepted socket connection from
...
08:18:57,010 [NIOServerCnxn.java:354] Exception causing close of session 0x0
due to java.io.IOException: ZooKeeperServer not running
08:18:57,010 [NIOServerCnxn.java:1001] Closed socket connection for client
... (no session established for client)
...
08:18:58,496 [FileTxnSnapLog.java:240] Snapshotting: ... to ...
{noformat}
+solr log extract+
{noformat}
08:18:54,968 [ClientCnxn.java:1085] Unable to read additional data from
server sessionid ... likely server has closed socket, closing socket
connection and attempting reconnect
08:18:55,068 [ConnectionManager.java:72] Watcher
org.apache.solr.common.cloud.ConnectionManager@... name:ZooKeeperConnection
Watcher:host1:port1,host2:port2,host3:port3,... got event WatchedEvent
state:Disconnected type:None path:null path:null type:None
08:18:55,068 [ConnectionManager.java:132] zkClient has disconnected
...
08:18:55,961 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:55,961 [ClientCnxn.java:849] Socket connection established to ...
08:18:55,962 [ClientCnxn.java:1085] Unable to read additional data from
server sessionid ... likely server has closed socket, closing socket
connection and attempting reconnect
...
08:18:56,714 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:56,715 [ClientCnxn.java:849] Socket connection established to ...
08:18:56,715 [ClientCnxn.java:1085] Unable to read additional data from ...
...
08:18:57,640 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:57,641 [ClientCnxn.java:849] Socket connection established to ...
08:18:57,641 [ClientCnxn.java:1085] Unable to read additional data from ...
...
08:18:58,352 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:58,353 [ClientCnxn.java:849] Socket connection established to ...
08:18:58,353 [ClientCnxn.java:1085] Unable to read additional data from ...
...
08:18:58,749 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:58,749 [ClientCnxn.java:849] Socket connection established to ...
08:18:58,751 [ClientCnxn.java:1207] Session establishment complete on server
... sessionid = ..., negotiated timeout = ...
08:18:58,751 ... [ConnectionManager.java:72] Watcher
org.apache.solr.common.cloud.ConnectionManager@... name:ZooKeeperConnection
Watcher:host1:port1,host2:port2,host3:port3,... got event WatchedEvent
state:SyncConnected type:None path:null path:null type:None
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5577) indexing delay due to zookeeper election
[
https://issues.apache.org/jira/browse/SOLR-5577?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876015#comment-13876015
]
ASF subversion and git services commented on SOLR-5577:
---
Commit 1559589 from [~markrmil...@gmail.com] in branch
'dev/branches/lucene_solr_4_6'
[ https://svn.apache.org/r1559589 ]
SOLR-5577: Harden leaking Timer thread.
indexing delay due to zookeeper election
Key: SOLR-5577
URL: https://issues.apache.org/jira/browse/SOLR-5577
Project: Solr
Issue Type: Bug
Components: SolrCloud
Reporter: Christine Poerschke
Assignee: Mark Miller
Fix For: 5.0, 4.7, 4.6.1
Attachments: SOLR-5577.patch
The behaviour we observed was that a zookeeper election took about 2s plus
1.5s for reading the zoo_data snapshot. During this time solr tried to
establish connections to any zookeeper in the ensemble but only succeeded
once a leader was elected *and* that leader was done reading the snapshot.
Solr document updates were slowed down during this time window.
Is this expected to happen during and shortly after elections, that is
zookeeper closing existing connections, rejecting new connections and thus
stalling solr updates?
Other than avoiding zookeeper elections, are there ways of reducing their
impact on solr?
+zookeeper log extract+
{noformat}
08:18:54,968 [QuorumCnxManager.java:762] Connection broken for id ...
08:18:56,916 [Leader.java:345] LEADING - LEADER ELECTION TOOK - 1941
08:18:56,918 [FileSnap.java:83] Reading snapshot ...
...
08:18:57,010 [NIOServerCnxnFactory.java:197] Accepted socket connection from
...
08:18:57,010 [NIOServerCnxn.java:354] Exception causing close of session 0x0
due to java.io.IOException: ZooKeeperServer not running
08:18:57,010 [NIOServerCnxn.java:1001] Closed socket connection for client
... (no session established for client)
...
08:18:58,496 [FileTxnSnapLog.java:240] Snapshotting: ... to ...
{noformat}
+solr log extract+
{noformat}
08:18:54,968 [ClientCnxn.java:1085] Unable to read additional data from
server sessionid ... likely server has closed socket, closing socket
connection and attempting reconnect
08:18:55,068 [ConnectionManager.java:72] Watcher
org.apache.solr.common.cloud.ConnectionManager@... name:ZooKeeperConnection
Watcher:host1:port1,host2:port2,host3:port3,... got event WatchedEvent
state:Disconnected type:None path:null path:null type:None
08:18:55,068 [ConnectionManager.java:132] zkClient has disconnected
...
08:18:55,961 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:55,961 [ClientCnxn.java:849] Socket connection established to ...
08:18:55,962 [ClientCnxn.java:1085] Unable to read additional data from
server sessionid ... likely server has closed socket, closing socket
connection and attempting reconnect
...
08:18:56,714 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:56,715 [ClientCnxn.java:849] Socket connection established to ...
08:18:56,715 [ClientCnxn.java:1085] Unable to read additional data from ...
...
08:18:57,640 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:57,641 [ClientCnxn.java:849] Socket connection established to ...
08:18:57,641 [ClientCnxn.java:1085] Unable to read additional data from ...
...
08:18:58,352 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:58,353 [ClientCnxn.java:849] Socket connection established to ...
08:18:58,353 [ClientCnxn.java:1085] Unable to read additional data from ...
...
08:18:58,749 [ClientCnxn.java:966] Opening socket connection to server ...
08:18:58,749 [ClientCnxn.java:849] Socket connection established to ...
08:18:58,751 [ClientCnxn.java:1207] Session establishment complete on server
... sessionid = ..., negotiated timeout = ...
08:18:58,751 ... [ConnectionManager.java:72] Watcher
org.apache.solr.common.cloud.ConnectionManager@... name:ZooKeeperConnection
Watcher:host1:port1,host2:port2,host3:port3,... got event WatchedEvent
state:SyncConnected type:None path:null path:null type:None
{noformat}
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5099) QueryNode should have the ability to detach from its node parent
[ https://issues.apache.org/jira/browse/LUCENE-5099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adriano Crestani updated LUCENE-5099: - Summary: QueryNode should have the ability to detach from its node parent (was: QueryNodeProcessorImpl should set parent to nulll before returning on processing) QueryNode should have the ability to detach from its node parent Key: LUCENE-5099 URL: https://issues.apache.org/jira/browse/LUCENE-5099 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 3.6.2, 4.3.1 Reporter: Adriano Crestani Assignee: Adriano Crestani QueryNodeProcessorImpl should always return the root of the tree after processing, so it needs to make the parent is set to null before returning. Otherwise, the previous parent is leaked and never removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5099) QueryNode should have the ability to detach from its node parent
[ https://issues.apache.org/jira/browse/LUCENE-5099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876016#comment-13876016 ] Adriano Crestani commented on LUCENE-5099: -- After some investigation, I reached the conclusion that QueryNodeProcessorImpl should never take the decision of detaching the returned processed node from its parent. It should be up to the processor implementor logic or to the processor user to take that decision. For that reason, I have renamed this JIRA. Instead, we should add a method to QueryNode so the processor implementor or user could detach nodes from their parents. QueryNode should have the ability to detach from its node parent Key: LUCENE-5099 URL: https://issues.apache.org/jira/browse/LUCENE-5099 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 3.6.2, 4.3.1 Reporter: Adriano Crestani Assignee: Adriano Crestani QueryNodeProcessorImpl should always return the root of the tree after processing, so it needs to make the parent is set to null before returning. Otherwise, the previous parent is leaked and never removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5099) QueryNode should have the ability to detach from its node parent
[ https://issues.apache.org/jira/browse/LUCENE-5099?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adriano Crestani updated LUCENE-5099: - Attachment: LUCENE-5099_adrianocrestani_2014-01-19.patch LUCENE-5099_adrianocrestani_2014-01-19_4x.patch These are the proposed changes. I will commit in a couple of days if there are no objections. QueryNode should have the ability to detach from its node parent Key: LUCENE-5099 URL: https://issues.apache.org/jira/browse/LUCENE-5099 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 3.6.2, 4.3.1 Reporter: Adriano Crestani Assignee: Adriano Crestani Attachments: LUCENE-5099_adrianocrestani_2014-01-19.patch, LUCENE-5099_adrianocrestani_2014-01-19_4x.patch QueryNodeProcessorImpl should always return the root of the tree after processing, so it needs to make the parent is set to null before returning. Otherwise, the previous parent is leaked and never removed. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5633) HttpShardHandlerFactory should make its http client available to subclasses
[ https://issues.apache.org/jira/browse/SOLR-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-5633. --- Resolution: Fixed HttpShardHandlerFactory should make its http client available to subclasses --- Key: SOLR-5633 URL: https://issues.apache.org/jira/browse/SOLR-5633 Project: Solr Issue Type: Improvement Reporter: Ryan Ernst Assignee: Ryan Ernst Fix For: 5.0, 4.7 Attachments: SOLR-5633.patch To save on doubling up on resources, the SHF should have its http client protected (so subclasses can do things like custom status checks). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5633) HttpShardHandlerFactory should make its http client available to subclasses
[ https://issues.apache.org/jira/browse/SOLR-5633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5633: -- Fix Version/s: 4.7 5.0 HttpShardHandlerFactory should make its http client available to subclasses --- Key: SOLR-5633 URL: https://issues.apache.org/jira/browse/SOLR-5633 Project: Solr Issue Type: Improvement Reporter: Ryan Ernst Assignee: Ryan Ernst Fix For: 5.0, 4.7 Attachments: SOLR-5633.patch To save on doubling up on resources, the SHF should have its http client protected (so subclasses can do things like custom status checks). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5092) join: don't expect all filters to be FixedBitSet instances
[ https://issues.apache.org/jira/browse/LUCENE-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876032#comment-13876032 ] Paul Elschot commented on LUCENE-5092: -- There is an early version of DocBlockIterator.java at: https://github.com/PaulElschot/lucene-solr/blob/docblockiter/lucene/core/src/java/org/apache/lucene/search/DocBlockIterator.java This defines advanceToJustBefore() by: advanceToJustBefore() followed by nextDoc() === advance() Comments? join: don't expect all filters to be FixedBitSet instances -- Key: LUCENE-5092 URL: https://issues.apache.org/jira/browse/LUCENE-5092 Project: Lucene - Core Issue Type: Improvement Components: modules/join Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-5092.patch The join module throws exceptions when the parents filter isn't a FixedBitSet. The reason is that the join module relies on prevSetBit to find the first child document given a parent ID. As suggested by Uwe and Paul Elschot on LUCENE-5081, we could fix it by exposing methods in the iterators to iterate backwards. When the join modules gets an iterator which isn't able to iterate backwards, it would just need to dump its content into another DocIdSet that supports backward iteration, FixedBitSet for example. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5404) Add support to get number of entries a Suggester Lookup was built with and minor refactorings
[ https://issues.apache.org/jira/browse/LUCENE-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Areek Zillur updated LUCENE-5404: - Attachment: LUCENE-5404.patch Updated Patch: - count() - getCount() - doc to make it clear that count represents only the entries the iterator has seen so far Regarding the getCount() in the InputIterator API, it is just the number of entries the iterator has seen so far. So it will be valid to call it only after a Lookup has consumed all the entries from the Iterator. I think it will be something useful to know the # of entries a lookup was built with, given some of the iterator skips 'invalid' entries as it feeds it to the lookups? I can also see this being useful when suggesters are run in distributed mode, maybe when shards dont respond, this can be used to report the % of entries that the lookup ran against? Add support to get number of entries a Suggester Lookup was built with and minor refactorings - Key: LUCENE-5404 URL: https://issues.apache.org/jira/browse/LUCENE-5404 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Areek Zillur Fix For: 5.0, 4.7 Attachments: LUCENE-5404.patch, LUCENE-5404.patch It would be nice to be able to tell the number of entries a suggester lookup was built with. This would let components using lookups to keep some stats regarding how many entries were used to build a lookup. Additionally, Dictionary could use InputIterator rather than the BytesRefIteratator, as most of the implmentations now use it. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5404) Add support to get number of entries a Suggester Lookup was built with and minor refactorings
[ https://issues.apache.org/jira/browse/LUCENE-5404?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876033#comment-13876033 ] Areek Zillur edited comment on LUCENE-5404 at 1/19/14 10:36 PM: Updated Patch (Thanks for the review Michael and Robert): - count() - getCount() - doc to make it clear that count represents only the entries the iterator has seen so far Regarding the getCount() in the InputIterator API, it is just the number of entries the iterator has seen so far. So it will be valid to call it only after a Lookup has consumed all the entries from the Iterator. I think it will be something useful to know the # of entries a lookup was built with, given some of the iterator skips 'invalid' entries as it feeds it to the lookups? I can also see this being useful when suggesters are run in distributed mode, maybe when shards dont respond, this can be used to report the % of entries that the lookup ran against? was (Author: areek): Updated Patch: - count() - getCount() - doc to make it clear that count represents only the entries the iterator has seen so far Regarding the getCount() in the InputIterator API, it is just the number of entries the iterator has seen so far. So it will be valid to call it only after a Lookup has consumed all the entries from the Iterator. I think it will be something useful to know the # of entries a lookup was built with, given some of the iterator skips 'invalid' entries as it feeds it to the lookups? I can also see this being useful when suggesters are run in distributed mode, maybe when shards dont respond, this can be used to report the % of entries that the lookup ran against? Add support to get number of entries a Suggester Lookup was built with and minor refactorings - Key: LUCENE-5404 URL: https://issues.apache.org/jira/browse/LUCENE-5404 Project: Lucene - Core Issue Type: Improvement Components: core/search Reporter: Areek Zillur Fix For: 5.0, 4.7 Attachments: LUCENE-5404.patch, LUCENE-5404.patch It would be nice to be able to tell the number of entries a suggester lookup was built with. This would let components using lookups to keep some stats regarding how many entries were used to build a lookup. Additionally, Dictionary could use InputIterator rather than the BytesRefIteratator, as most of the implmentations now use it. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC1
On 1/19/2014 12:59 PM, Mark Miller wrote: Unfortunately, I think SOLR-5645 is probably worth a re spin. I think otherwise, collection reloads will be unstable vs 4.6. Collection reloads were unstable once before, SOLR-4805. A lot of people were hit by that one. I was very glad when SOLR-4805 was fixed and we could tell people that relief was coming. I admit that I don't know why registering in ZK again is bad, but if you think the issue warrants a re-spin, I'm inclined to put my vote in that basket. -1, please respin. In other news, when I tried Friday to run nightly-smoke on the SVN checkout used to build the RC, it failed, said that a jarfile was missing something like Created by 1.6 ... which seemed more like a problem with my setup than the code. I can obtain the exact error message by running it again, but does anyone know what my problem might be? I have Java 6u26 and 7u25 installed on a Debian system. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC1
If you are building the artifacts, you have to make sure it's using Java 6 rather than 7. IMO on linux, ant picks up what is set by the JAVA_HOME env variable. - Mark On Sun, Jan 19, 2014 at 5:57 PM, Shawn Heisey s...@elyograg.org wrote: On 1/19/2014 12:59 PM, Mark Miller wrote: Unfortunately, I think SOLR-5645 is probably worth a re spin. I think otherwise, collection reloads will be unstable vs 4.6. Collection reloads were unstable once before, SOLR-4805. A lot of people were hit by that one. I was very glad when SOLR-4805 was fixed and we could tell people that relief was coming. I admit that I don't know why registering in ZK again is bad, but if you think the issue warrants a re-spin, I'm inclined to put my vote in that basket. -1, please respin. In other news, when I tried Friday to run nightly-smoke on the SVN checkout used to build the RC, it failed, said that a jarfile was missing something like Created by 1.6 ... which seemed more like a problem with my setup than the code. I can obtain the exact error message by running it again, but does anyone know what my problem might be? I have Java 6u26 and 7u25 installed on a Debian system. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Mark
[jira] [Commented] (LUCENE-5355) Add more support to validate the -Dbootclasspath given for javadocs generate
[
https://issues.apache.org/jira/browse/LUCENE-5355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876044#comment-13876044
]
ASF subversion and git services commented on LUCENE-5355:
-
Commit 1559597 from [~thetaphi] in branch 'dev/branches/lucene_solr_4_6'
[ https://svn.apache.org/r1559597 ]
Backport this to 4.6, so we can be sure that next release has correct version
and bootclasspath for nice javadocs:
Merged revision(s) 1547347 from lucene/dev/branches/branch_4x:
LUCENE-5355: Add support for -Dbootjdk to point to a separate JAVA_HOME that is
used to generate javadocs; validate the -Dbootclasspath to point to a valid
rt.jar
Add more support to validate the -Dbootclasspath given for javadocs generate
Key: LUCENE-5355
URL: https://issues.apache.org/jira/browse/LUCENE-5355
Project: Lucene - Core
Issue Type: Improvement
Components: general/build
Affects Versions: 4.6
Environment: MacOSX AppleJDK6
Reporter: Uwe Schindler
Assignee: Uwe Schindler
Fix For: 5.0, 4.7
Attachments: LUCENE-5355.patch
When Simon created the nice looking javadocs for LuSolr 4.6, he just
copypasted the command line from
http://wiki.apache.org/lucene-java/HowToGenerateNiceJavadocs
Unfortunately this does not work with AppleJDK6, because it has no rt.jar!
The rt.jar file is there in a completely different directory and is named
classes.jar. I had a similar problem when I wanted to regenerate the Javadocs
on my Linux box, but specified {{-Dbootclasspath}} with shell specials (e.g.,
{{~}} for homedir).
This patch will assist the user and will validate the given bootclasspath,
so it points to a JAR file that actually contains the runtime. Also to make
life easier, instead of {{-Dbootclasspath}} you can set {{-Dbootjdk}} to the
JDK homefolder (same like JAVA_HOME) and ANT will figure out if it is Apple
or Oracle or maybe only a JRE.
In the meantime, I regenerated the 4.6 Javadocs with correct bootclasspath.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] Release Lucene/Solr 4.6.1 RC1
Hi Mark, This problem lets me remember LUCENE-5355: This one affected the “nice” javadocs created after release. I backported the patch, so the one running the “nice looking javadocs” on java 7 with java 6 bootclasspath can be sure, it was really using the correct bootclasspath. Also the documentation howto on the wiki applies only to builds with this patch. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: u...@thetaphi.de From: Mark Miller [mailto:markrmil...@gmail.com] Sent: Monday, January 20, 2014 12:05 AM To: dev@lucene.apache.org Subject: Re: [VOTE] Release Lucene/Solr 4.6.1 RC1 If you are building the artifacts, you have to make sure it's using Java 6 rather than 7. IMO on linux, ant picks up what is set by the JAVA_HOME env variable. - Mark On Sun, Jan 19, 2014 at 5:57 PM, Shawn Heisey s...@elyograg.org wrote: On 1/19/2014 12:59 PM, Mark Miller wrote: Unfortunately, I think SOLR-5645 is probably worth a re spin. I think otherwise, collection reloads will be unstable vs 4.6. Collection reloads were unstable once before, SOLR-4805. A lot of people were hit by that one. I was very glad when SOLR-4805 was fixed and we could tell people that relief was coming. I admit that I don't know why registering in ZK again is bad, but if you think the issue warrants a re-spin, I'm inclined to put my vote in that basket. -1, please respin. In other news, when I tried Friday to run nightly-smoke on the SVN checkout used to build the RC, it failed, said that a jarfile was missing something like Created by 1.6 ... which seemed more like a problem with my setup than the code. I can obtain the exact error message by running it again, but does anyone know what my problem might be? I have Java 6u26 and 7u25 installed on a Debian system. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- - Mark
[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch
[
https://issues.apache.org/jira/browse/SOLR-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876046#comment-13876046
]
ASF subversion and git services commented on SOLR-5608:
---
Commit 1559600 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1559600 ]
SOLR-5608: Harden test.
Frequently reproducible failures in
CollectionsAPIDistributedZkTest#testDistribSearch
-
Key: SOLR-5608
URL: https://issues.apache.org/jira/browse/SOLR-5608
Project: Solr
Issue Type: Bug
Components: Tests
Affects Versions: 4.7
Environment: uname -a:
Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64
GNU/Linux
java -version:
java version 1.7.0_25
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
svn info:
Path: .
Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1555600
Node Kind: directory
Schedule: normal
Last Changed Author: uschindler
Last Changed Rev: 157
Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
Fix For: 5.0, 4.7, 4.6.1
Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt,
SOLR-5608-failure3.txt, SOLR-5608-lshw.txt
This is what looks like the relevant piece of the failure.
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch
-Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT
-Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 179s | CollectionsAPIDistributedZkTest.testDistribSearch
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at
__randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
{noformat}
This jenkins failure looks like it may be similar:
http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch
[
https://issues.apache.org/jira/browse/SOLR-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876047#comment-13876047
]
ASF subversion and git services commented on SOLR-5608:
---
Commit 1559602 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1559602 ]
SOLR-5608: Harden test.
Frequently reproducible failures in
CollectionsAPIDistributedZkTest#testDistribSearch
-
Key: SOLR-5608
URL: https://issues.apache.org/jira/browse/SOLR-5608
Project: Solr
Issue Type: Bug
Components: Tests
Affects Versions: 4.7
Environment: uname -a:
Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64
GNU/Linux
java -version:
java version 1.7.0_25
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
svn info:
Path: .
Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1555600
Node Kind: directory
Schedule: normal
Last Changed Author: uschindler
Last Changed Rev: 157
Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
Fix For: 5.0, 4.7, 4.6.1
Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt,
SOLR-5608-failure3.txt, SOLR-5608-lshw.txt
This is what looks like the relevant piece of the failure.
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch
-Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT
-Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 179s | CollectionsAPIDistributedZkTest.testDistribSearch
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at
__randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
{noformat}
This jenkins failure looks like it may be similar:
http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch
[
https://issues.apache.org/jira/browse/SOLR-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876049#comment-13876049
]
Mark Miller commented on SOLR-5608:
---
*now* I think I've gotten it ;)
Frequently reproducible failures in
CollectionsAPIDistributedZkTest#testDistribSearch
-
Key: SOLR-5608
URL: https://issues.apache.org/jira/browse/SOLR-5608
Project: Solr
Issue Type: Bug
Components: Tests
Affects Versions: 4.7
Environment: uname -a:
Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64
GNU/Linux
java -version:
java version 1.7.0_25
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
svn info:
Path: .
Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1555600
Node Kind: directory
Schedule: normal
Last Changed Author: uschindler
Last Changed Rev: 157
Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
Fix For: 5.0, 4.7, 4.6.1
Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt,
SOLR-5608-failure3.txt, SOLR-5608-lshw.txt
This is what looks like the relevant piece of the failure.
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch
-Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT
-Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 179s | CollectionsAPIDistributedZkTest.testDistribSearch
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at
__randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
{noformat}
This jenkins failure looks like it may be similar:
http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch
[
https://issues.apache.org/jira/browse/SOLR-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876050#comment-13876050
]
ASF subversion and git services commented on SOLR-5608:
---
Commit 1559608 from [~markrmil...@gmail.com] in branch
'dev/branches/lucene_solr_4_6'
[ https://svn.apache.org/r1559608 ]
SOLR-5608: Harden test.
Frequently reproducible failures in
CollectionsAPIDistributedZkTest#testDistribSearch
-
Key: SOLR-5608
URL: https://issues.apache.org/jira/browse/SOLR-5608
Project: Solr
Issue Type: Bug
Components: Tests
Affects Versions: 4.7
Environment: uname -a:
Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64
GNU/Linux
java -version:
java version 1.7.0_25
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
svn info:
Path: .
Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1555600
Node Kind: directory
Schedule: normal
Last Changed Author: uschindler
Last Changed Rev: 157
Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
Fix For: 5.0, 4.7, 4.6.1
Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt,
SOLR-5608-failure3.txt, SOLR-5608-lshw.txt
This is what looks like the relevant piece of the failure.
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch
-Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT
-Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 179s | CollectionsAPIDistributedZkTest.testDistribSearch
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at
__randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
{noformat}
This jenkins failure looks like it may be similar:
http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch
[
https://issues.apache.org/jira/browse/SOLR-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876051#comment-13876051
]
ASF subversion and git services commented on SOLR-5608:
---
Commit 1559609 from [~markrmil...@gmail.com] in branch 'dev/trunk'
[ https://svn.apache.org/r1559609 ]
SOLR-5608: Raise wait for leader timeout from 1000 to 15000
Frequently reproducible failures in
CollectionsAPIDistributedZkTest#testDistribSearch
-
Key: SOLR-5608
URL: https://issues.apache.org/jira/browse/SOLR-5608
Project: Solr
Issue Type: Bug
Components: Tests
Affects Versions: 4.7
Environment: uname -a:
Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64
GNU/Linux
java -version:
java version 1.7.0_25
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
svn info:
Path: .
Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1555600
Node Kind: directory
Schedule: normal
Last Changed Author: uschindler
Last Changed Rev: 157
Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
Fix For: 5.0, 4.7, 4.6.1
Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt,
SOLR-5608-failure3.txt, SOLR-5608-lshw.txt
This is what looks like the relevant piece of the failure.
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch
-Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT
-Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 179s | CollectionsAPIDistributedZkTest.testDistribSearch
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at
__randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
{noformat}
This jenkins failure looks like it may be similar:
http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch
[
https://issues.apache.org/jira/browse/SOLR-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876052#comment-13876052
]
ASF subversion and git services commented on SOLR-5608:
---
Commit 1559610 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1559610 ]
SOLR-5608: Raise wait for leader timeout from 1000 to 15000
Frequently reproducible failures in
CollectionsAPIDistributedZkTest#testDistribSearch
-
Key: SOLR-5608
URL: https://issues.apache.org/jira/browse/SOLR-5608
Project: Solr
Issue Type: Bug
Components: Tests
Affects Versions: 4.7
Environment: uname -a:
Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64
GNU/Linux
java -version:
java version 1.7.0_25
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
svn info:
Path: .
Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1555600
Node Kind: directory
Schedule: normal
Last Changed Author: uschindler
Last Changed Rev: 157
Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
Fix For: 5.0, 4.7, 4.6.1
Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt,
SOLR-5608-failure3.txt, SOLR-5608-lshw.txt
This is what looks like the relevant piece of the failure.
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch
-Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT
-Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 179s | CollectionsAPIDistributedZkTest.testDistribSearch
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at
__randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
{noformat}
This jenkins failure looks like it may be similar:
http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC1
On 1/19/2014 4:04 PM, Mark Miller wrote: If you are building the artifacts, you have to make sure it's using Java 6 rather than 7. IMO on linux, ant picks up what is set by the JAVA_HOME env variable. The /etc/alternatives links point all the main java executables to 7u25. 6u26 is available. JAVA6_HOME and JAVA7_HOME were both set. JAVA_HOME was not. I'll do some experimentation ... although I would think that if java 6 is required, it could use the information it's been given about java 6. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5643) ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue.
[ https://issues.apache.org/jira/browse/SOLR-5643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5643: -- Attachment: SOLR-5643.patch I think that this will address it. I've been testing it with a case that I found while working on SOLR-4260. ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue. --- Key: SOLR-5643 URL: https://issues.apache.org/jira/browse/SOLR-5643 Project: Solr Issue Type: Bug Reporter: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-5643.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC1
Should have been in my experience, not imo - have had a cold for a week and it’s getting to me. bq. it could use the information it's been given about java 6. I think it’s an Apache Ant thing. JAVA6_HOME and JAVA7_HOME are Lucene smoke tester things. - Mark On Jan 19, 2014, at 9:02 PM, Shawn Heisey s...@elyograg.org wrote: On 1/19/2014 4:04 PM, Mark Miller wrote: If you are building the artifacts, you have to make sure it's using Java 6 rather than 7. IMO on linux, ant picks up what is set by the JAVA_HOME env variable. The /etc/alternatives links point all the main java executables to 7u25. 6u26 is available. JAVA6_HOME and JAVA7_HOME were both set. JAVA_HOME was not. I'll do some experimentation ... although I would think that if java 6 is required, it could use the information it's been given about java 6. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-5643) ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue.
[ https://issues.apache.org/jira/browse/SOLR-5643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-5643: - Assignee: Mark Miller ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue. --- Key: SOLR-5643 URL: https://issues.apache.org/jira/browse/SOLR-5643 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-5643.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[VOTE] Release Lucene/Solr 4.6.1 RC2
Please vote to release the following artifacts: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1559610/ Here is my +1. SUCCESS! [0:51:51.964657] -- - Mark
[VOTE] Release Lucene/Solr 4.6.1 RC2
Please vote to release the following artifacts: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1559610/ Here is my +1. SUCCESS! [0:51:51.964657] -- - Mark
[jira] [Commented] (SOLR-5643) ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue.
[ https://issues.apache.org/jira/browse/SOLR-5643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876109#comment-13876109 ] ASF subversion and git services commented on SOLR-5643: --- Commit 1559620 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1559620 ] SOLR-5643: ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue. ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue. --- Key: SOLR-5643 URL: https://issues.apache.org/jira/browse/SOLR-5643 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-5643.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5643) ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue.
[ https://issues.apache.org/jira/browse/SOLR-5643?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876110#comment-13876110 ] ASF subversion and git services commented on SOLR-5643: --- Commit 1559621 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1559621 ] SOLR-5643: ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue. ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue. --- Key: SOLR-5643 URL: https://issues.apache.org/jira/browse/SOLR-5643 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-5643.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5646) SolrEventListener listener should have destroy function
Raintung Li created SOLR-5646: - Summary: SolrEventListener listener should have destroy function Key: SOLR-5646 URL: https://issues.apache.org/jira/browse/SOLR-5646 Project: Solr Issue Type: Improvement Components: multicore Affects Versions: 4.6, 4.5.1, 4.5 Environment: normal multiple core Reporter: Raintung Li solr can support the self listener, but only register the listener in the core load, but don't have destroy function while core close/server shutdown. SolrEventListener can provide the destroy function to be invoked by core close, that can destroy listener resource. (Thread or Cache or others) -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5608) Frequently reproducible failures in CollectionsAPIDistributedZkTest#testDistribSearch
[
https://issues.apache.org/jira/browse/SOLR-5608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876126#comment-13876126
]
Mark Miller commented on SOLR-5608:
---
Nope, still more to do here...
Frequently reproducible failures in
CollectionsAPIDistributedZkTest#testDistribSearch
-
Key: SOLR-5608
URL: https://issues.apache.org/jira/browse/SOLR-5608
Project: Solr
Issue Type: Bug
Components: Tests
Affects Versions: 4.7
Environment: uname -a:
Linux frodo 2.6.32-5-amd64 #1 SMP Mon Sep 23 22:14:43 UTC 2013 x86_64
GNU/Linux
java -version:
java version 1.7.0_25
Java(TM) SE Runtime Environment (build 1.7.0_25-b15)
Java HotSpot(TM) 64-Bit Server VM (build 23.25-b01, mixed mode)
svn info:
Path: .
Working Copy Root Path: /home/elyograg/lucene-solr/branch_4x
URL: https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/solr
Repository Root: https://svn.apache.org/repos/asf
Repository UUID: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 1555600
Node Kind: directory
Schedule: normal
Last Changed Author: uschindler
Last Changed Rev: 157
Last Changed Date: 2014-01-05 09:17:54 -0700 (Sun, 05 Jan 2014)
Reporter: Shawn Heisey
Assignee: Mark Miller
Fix For: 5.0, 4.7, 4.6.1
Attachments: SOLR-5608-failure1.txt, SOLR-5608-failure2.txt,
SOLR-5608-failure3.txt, SOLR-5608-lshw.txt
This is what looks like the relevant piece of the failure.
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch
-Dtests.seed=45A6C046A15FD121 -Dtests.slow=true -Dtests.locale=it_IT
-Dtests.timezone=America/Creston -Dtests.file.encoding=US-ASCII
[junit4] FAILURE 179s | CollectionsAPIDistributedZkTest.testDistribSearch
[junit4] Throwable #1: java.lang.AssertionError
[junit4]at
__randomizedtesting.SeedInfo.seed([45A6C046A15FD121:C4404E5ED600B11D]:0)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.deleteCollectionWithDownNodes(CollectionsAPIDistributedZkTest.java:390)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:203)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:849)
[junit4]at java.lang.Thread.run(Thread.java:724)
{noformat}
This jenkins failure looks like it may be similar:
http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8868/
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5092) join: don't expect all filters to be FixedBitSet instances
[ https://issues.apache.org/jira/browse/LUCENE-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876136#comment-13876136 ] Mikhail Khludnev commented on LUCENE-5092: -- It seems great! join: don't expect all filters to be FixedBitSet instances -- Key: LUCENE-5092 URL: https://issues.apache.org/jira/browse/LUCENE-5092 Project: Lucene - Core Issue Type: Improvement Components: modules/join Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-5092.patch The join module throws exceptions when the parents filter isn't a FixedBitSet. The reason is that the join module relies on prevSetBit to find the first child document given a parent ID. As suggested by Uwe and Paul Elschot on LUCENE-5081, we could fix it by exposing methods in the iterators to iterate backwards. When the join modules gets an iterator which isn't able to iterate backwards, it would just need to dump its content into another DocIdSet that supports backward iteration, FixedBitSet for example. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC2
When running the smoke tester against RC2, I ran into the same test problem
that Simon fixed a week ago on branch_4x, but not on lucene_solr_4_6: [
http://svn.apache.org/r1557503]. My log is below.
Not worth a respin IMHO. Running smoke tester again.
-
[junit4] Suite: org.apache.lucene.search.highlight.TokenSourcesTest
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=TokenSourcesTest -Dtests.method=testPayloads
-Dtests.seed=946A89A8D57D4759 -Dtests.slow=true -Dtests.locale=mk_MK
-Dtests.timezone=America/Argentina/ComodRivadavia
-Dtests.file.encoding=Cp1252
[junit4] ERROR 0.11s J2 | TokenSourcesTest.testPayloads
[junit4] Throwable #1: java.lang.UnsupportedOperationException: 3.x
codec does not support payloads on vectors!
[junit4]at
__randomizedtesting.SeedInfo.seed([946A89A8D57D4759:8621A96B4E3D9C51]:0)
[junit4]at
org.apache.lucene.codecs.lucene3x.PreFlexRWTermVectorsWriter.startField(PreFlexRWTermVectorsWriter.java:82)
[junit4]at
org.apache.lucene.index.TermVectorsConsumerPerField.finishDocument(TermVectorsConsumerPerField.java:161)
[junit4]at
org.apache.lucene.index.TermVectorsConsumer.finishDocument(TermVectorsConsumer.java:111)
[junit4]at
org.apache.lucene.index.TermsHash.finishDocument(TermsHash.java:132)
[junit4]at
org.apache.lucene.index.DocInverter.finishDocument(DocInverter.java:68)
[junit4]at
org.apache.lucene.index.DocFieldProcessor.finishDocument(DocFieldProcessor.java:269)
[junit4]at
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:271)
[junit4]at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:453)
[junit4]at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1529)
[junit4]at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1199)
[junit4]at
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:146)
[junit4]at
org.apache.lucene.index.RandomIndexWriter.addDocument(RandomIndexWriter.java:108)
[junit4]at
org.apache.lucene.search.highlight.TokenSourcesTest.testPayloads(TokenSourcesTest.java:332)
[junit4]at java.lang.Thread.run(Thread.java:724)
[junit4] 2 NOTE: test params are: codec=Lucene3x,
sim=RandomSimilarityProvider(queryNorm=false,coord=yes): {field=IB
SPL-L3(800.0), text=IB LL-L1}, locale=mk_MK,
timezone=America/Argentina/ComodRivadavia
[junit4] 2 NOTE: Windows 7 6.1 amd64/Oracle Corporation 1.7.0_25
(64-bit)/cpus=8,threads=1,free=122872824,total=156368896
[junit4] 2 NOTE: All tests run in this JVM: [TokenSourcesTest]
[junit4] Completed on J2 in 2.66s, 6 tests, 1 error FAILURES!
On Sun, Jan 19, 2014 at 9:29 PM, Mark Miller markrmil...@gmail.com wrote:
Please vote to release the following artifacts:
http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1559610/
Here is my +1.
SUCCESS! [0:51:51.964657]
--
- Mark
[jira] [Updated] (LUCENE-5395) Upgrade Spatial4j to 0.4
[ https://issues.apache.org/jira/browse/LUCENE-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley updated LUCENE-5395: - Attachment: LUCENE-5395_Spatial4j_0_4.patch Patch attached. It was a bit of work because I weened Lucene/Solr off all of Spatial4j's deprecated things. I added a test to show that the old circle and rect syntax still work in Solr but there's no trace of it anywhere else. And instead of simply copying ParseUtils into Solr, I really wanted to improve and simplify it and all code using it. It's now SpatialUtils with just one real point parsing method. Arguably that should have been a separate Solr issue, but it's just an internal refactor. I still need to actually release Spatial4j 0.4 but I was waiting for me to finish this patch. I'll release it tomorrow. *I'll commit this patch in ~24 hours, subject to feedback.* I will open a separate issue for Solr to remove the old circle rect format from trunk, and to ask a relation question about point formats. Upgrade Spatial4j to 0.4 Key: LUCENE-5395 URL: https://issues.apache.org/jira/browse/LUCENE-5395 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.7 Attachments: LUCENE-5395_Spatial4j_0_4.patch Spatial4j 0.4 should be released the week of January 13th; a snapshot is published. A longer version of the delta from 0.4 is in [CHANGES.md|https://github.com/spatial4j/spatial4j/blob/master/CHANGES.md] A couple notable new features are: * Built-in WKT parser without relying on JTS. The older shape string format is deprecated. * A binary shape codec for reading writing the shapes to a byte-stream in a reasonably compact manner. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5646) SolrEventListener listener should have destroy function
[ https://issues.apache.org/jira/browse/SOLR-5646?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raintung Li updated SOLR-5646: -- Attachment: patch-5646 SolrEventListener listener should have destroy function --- Key: SOLR-5646 URL: https://issues.apache.org/jira/browse/SOLR-5646 Project: Solr Issue Type: Improvement Components: multicore Affects Versions: 4.5, 4.5.1, 4.6 Environment: normal multiple core Reporter: Raintung Li Labels: destroy, listener Attachments: patch-5646 Original Estimate: 12h Remaining Estimate: 12h solr can support the self listener, but only register the listener in the core load, but don't have destroy function while core close/server shutdown. SolrEventListener can provide the destroy function to be invoked by core close, that can destroy listener resource. (Thread or Cache or others) -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[
https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13876232#comment-13876232
]
Shalin Shekhar Mangar commented on SOLR-5477:
-
Some comments on the last patch:
# Why have two different sets of parameter names; 'requeststatus' with 'id' for
collection handler and 'reqstatus' with 'requestid' for
OverseerCollectionProcessor? Let's make it the same. Maybe just call it
'status' with a request_id?
# In CollectionHandler.handleSplitShardAction, the following can throw NPE if
ASYNC is not present. Use Boolean.parseBoolean instead:
{code}
if (req.getParams().get(ASYNC).equals(true)) {
props.put(ASYNC, true);
}
{code}
# Shouldn't the CollectionHandler should add support for async in all commands
and not just create collection and split?
# CollectionHandler.handleResponse should actually check for non-null value of
async Just checking if the key exists is not enough.
# I guess the client creating/managing the id part is not implemented in the
last patch.
# In DistributedQueue.createData -- there is debug logging that should be
marked with nocommit and removed
# DistributedQueue.getNumericId is an unused method
# DistributedQueue.containsValue creates a new String from byte[] with the
default charset. Similar issues with String.getBytes. Run ant
check-forbidden-apis from inside the solr folder for a full list.
# The completed queue and the failure queue are actually for
OverseerCollectionProcessor so they should be named appropriately i.e.
/overseer/collection-queue-completed and /overseer/collection-queue-failed
# Why are items being put in the completedQueue in Overseer? The async and
status support is only for collection commands not overseer commands.
# The OverseerCollectionProcessor.processMessage catches Throwables with this
patch. It should be changed back to catching Exception only.
# Processing OverseerCollectionProcessor tasks in multiple threads is a key
requirement because these tasks can be long running. Just making them
asynchronous is not enough. This hasn't been addressed in this patch yet.
Async execution of OverseerCollectionProcessor tasks
Key: SOLR-5477
URL: https://issues.apache.org/jira/browse/SOLR-5477
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Anshum Gupta
Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch
Typical collection admin commands are long running and it is very common to
have the requests get timed out. It is more of a problem if the cluster is
very large.Add an option to run these commands asynchronously
add an extra param async=true for all collection commands
the task is written to ZK and the caller is returned a task id.
as separate collection admin command will be added to poll the status of the
task
command=statusid=7657668909
if id is not passed all running async tasks should be listed
A separate queue is created to store in-process tasks . After the tasks are
completed the queue entry is removed. OverSeerColectionProcessor will perform
these tasks in multiple threads
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
