[jira] [Commented] (SOLR-3993) SolrCloud leader election on single node stucks the initialization
[ https://issues.apache.org/jira/browse/SOLR-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503023#comment-13503023 ] Po Rui commented on SOLR-3993: -- To Werner: 1)are you sure your solr is 4.0 rather than 4.0alpha or 4.0beta? generally, the situation you described lead a lot of waitForReplicasComeup log produced. if no exception it will stop 3 mins latter. those logs due to zookeeper keep those old server's info in clustersate. 2) above situation both refer to zookeeper leader reelection.all solr service can't work before this election procedure over. the solr node may die if the election time over the solr connect-zookeeper retry time. so the problem is hard to deal with since the zook leader reelection procedure is uncontrollable. > SolrCloud leader election on single node stucks the initialization > -- > > Key: SOLR-3993 > URL: https://issues.apache.org/jira/browse/SOLR-3993 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 > Environment: Windows 7, Tomcat 6 >Reporter: Alexey Kudinov >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > > setup: > 1 node, 4 cores, 2 shards. > 15 documents indexed. > problem: > init stage times out. > probable cause: > According to the init flow, cores are initialized one by one synchronously. > Actually, the main thread waits > ShardLeaderElectionContext.waitForReplicasToComeUp until retry threshold, > while replica cores are not yet initialized, in other words there is no > chance other replicas go up in the meanwhile. > stack trace: > Thread [main] (Suspended) > owns: HashMap (id=3876) > owns: StandardContext (id=3877) > owns: HashMap (id=3878) > owns: StandardHost (id=3879) > owns: StandardEngine (id=3880) > owns: Service[] (id=3881) > Thread.sleep(long) line: not available [native method] > ShardLeaderElectionContext.waitForReplicasToComeUp(boolean, String) > line: 298 > ShardLeaderElectionContext.runLeaderProcess(boolean) line: 143 > LeaderElector.runIamLeaderProcess(ElectionContext, boolean) line: 152 > LeaderElector.checkIfIamLeader(int, ElectionContext, boolean) line: 96 > LeaderElector.joinElection(ElectionContext) line: 262 > ZkController.joinElection(CoreDescriptor, boolean) line: 733 > ZkController.register(String, CoreDescriptor, boolean, boolean) line: > 566 > ZkController.register(String, CoreDescriptor) line: 532 > CoreContainer.registerInZk(SolrCore) line: 709 > CoreContainer.register(String, SolrCore, boolean) line: 693 > CoreContainer.load(String, InputSource) line: 535 > CoreContainer.load(String, File) line: 356 > CoreContainer$Initializer.initialize() line: 308 > SolrDispatchFilter.init(FilterConfig) line: 107 > ApplicationFilterConfig.getFilter() line: 295 > ApplicationFilterConfig.setFilterDef(FilterDef) line: 422 > ApplicationFilterConfig.(Context, FilterDef) line: 115 > StandardContext.filterStart() line: 4072 > StandardContext.start() line: 4726 > StandardHost(ContainerBase).addChildInternal(Container) line: 799 > StandardHost(ContainerBase).addChild(Container) line: 779 > StandardHost.addChild(Container) line: 601 > HostConfig.deployDescriptor(String, File, String) line: 675 > HostConfig.deployDescriptors(File, String[]) line: 601 > HostConfig.deployApps() line: 502 > HostConfig.start() line: 1317 > HostConfig.lifecycleEvent(LifecycleEvent) line: 324 > LifecycleSupport.fireLifecycleEvent(String, Object) line: 142 > StandardHost(ContainerBase).start() line: 1065 > StandardHost.start() line: 840 > StandardEngine(ContainerBase).start() line: 1057 > StandardEngine.start() line: 463 > StandardService.start() line: 525 > StandardServer.start() line: 754 > Catalina.start() line: 595 > NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not > available [native method] > NativeMethodAccessorImpl.invoke(Object, Object[]) line: not available > DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: not > available > Method.invoke(Object, Object...) line: not available > Bootstrap.start() line: 289 > Bootstrap.main(String[]) line: 414 > > After a while, the session times out and following exception appears: > Oct 25, 2012 1:16:56 PM org.apache.solr.cloud.ShardLeaderElectionContext > waitForReplicasToComeUp > INFO: Waiting until we see more replicas up: total=2 found=0 timeoutin=-95 > Oct 25, 2012 1:16:56 PM org.apache.solr.clou
[jira] [Commented] (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13503003#comment-13503003 ] Jack Krupansky commented on SOLR-139: - Thanks! > Support updateable/modifiable documents > --- > > Key: SOLR-139 > URL: https://issues.apache.org/jira/browse/SOLR-139 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Ryan McKinley > Fix For: 4.0 > > Attachments: Eriks-ModifiableDocument.patch, > Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, > Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, > Eriks-ModifiableDocument.patch, getStoredFields.patch, getStoredFields.patch, > getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, > SOLR-139_createIfNotExist.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, > SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, > SOLR-139.patch, SOLR-139.patch, SOLR-139-XmlUpdater.patch, > SOLR-269+139-ModifiableDocumentUpdateProcessor.patch > > > It would be nice to be able to update some fields on a document without > having to insert the entire document. > Given the way lucene is structured, (for now) one can only modify stored > fields. > While we are at it, we can support incrementing an existing value - I think > this only makes sense for numbers. > for background, see: > http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-139) Support updateable/modifiable documents
[ https://issues.apache.org/jira/browse/SOLR-139?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-139. --- Resolution: Fixed Fix Version/s: (was: 4.1) 4.0 > Support updateable/modifiable documents > --- > > Key: SOLR-139 > URL: https://issues.apache.org/jira/browse/SOLR-139 > Project: Solr > Issue Type: New Feature > Components: update >Reporter: Ryan McKinley > Fix For: 4.0 > > Attachments: Eriks-ModifiableDocument.patch, > Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, > Eriks-ModifiableDocument.patch, Eriks-ModifiableDocument.patch, > Eriks-ModifiableDocument.patch, getStoredFields.patch, getStoredFields.patch, > getStoredFields.patch, getStoredFields.patch, getStoredFields.patch, > SOLR-139_createIfNotExist.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-IndexDocumentCommand.patch, SOLR-139-IndexDocumentCommand.patch, > SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, > SOLR-139-ModifyInputDocuments.patch, SOLR-139-ModifyInputDocuments.patch, > SOLR-139.patch, SOLR-139.patch, SOLR-139-XmlUpdater.patch, > SOLR-269+139-ModifiableDocumentUpdateProcessor.patch > > > It would be nice to be able to update some fields on a document without > having to insert the entire document. > Given the way lucene is structured, (for now) one can only modify stored > fields. > While we are at it, we can support incrementing an existing value - I think > this only makes sense for numbers. > for background, see: > http://www.nabble.com/loading-many-documents-by-ID-tf3145666.html#a8722293 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3304) Add Solr support for the new Lucene spatial module
[ https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502988#comment-13502988 ] Ari Maniatis commented on SOLR-3304: I know this is not a support forum, but for your reference, here are the issues our developer is struggling to find Solr4 documentation for: 1) filter by the distance between course location field and Intersects(Circle) calculated by passed suburb params always returns empty result if we use solr.SpatialRecursivePrefixTreeFieldType filed type (as described in documentation this query and configuration changes should be used to kick off the plugin). 2) updated org.apache.solr.schema.GeoHashField field type does not support geodist for multivalued fields and I not found the way how we can adjust this type to the same functionality as we have in SOLR-2155 plugin. > Add Solr support for the new Lucene spatial module > -- > > Key: SOLR-3304 > URL: https://issues.apache.org/jira/browse/SOLR-3304 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.0-ALPHA >Reporter: Bill Bell >Assignee: David Smiley >Priority: Critical > Labels: spatial > Fix For: 4.0 > > Attachments: SOLR-3304_Solr_fields_for_Lucene_spatial_module > (fieldName in Strategy) - indexableFields.patch, > SOLR-3304_Solr_fields_for_Lucene_spatial_module (fieldName in > Strategy).patch, SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, > SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, > SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, > SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, > SOLR-3304-strategy-getter-fixed.patch > > > Get the Solr spatial module integrated with the lucene spatial module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Status of SOLR-139 - Support updateable/modifiable documents
Great question. It is indeed one possible future, as is LUCENE-3837. All the more reason to close SOLR-139. -- Jack Krupansky From: Otis Gospodnetic Sent: Thursday, November 22, 2012 8:09 PM To: dev@lucene.apache.org Subject: Re: Status of SOLR-139 - Support updateable/modifiable documents Hey Jack, Isn't LUCENE-4258 the future? Otis -- SOLR Performance Monitoring - http://sematext.com/spm On Nov 22, 2012 7:33 PM, "Jack Krupansky" wrote: If I understand correctly, SOLR-139, Support updateable/modifiable documents, is in Solr 4.0, but the issue is still open pending further enhancements. Since SOLR-139 is already in CHANGES.txt for 4.0, can I suggest that the issue be closed and any further improvements be separate issues to avoid confusion in CHANGES.txt? See: https://issues.apache.org/jira/browse/SOLR-139 -- Jack Krupansky
Re: Status of SOLR-139 - Support updateable/modifiable documents
Hey Jack, Isn't LUCENE-4258 the future? Otis -- SOLR Performance Monitoring - http://sematext.com/spm On Nov 22, 2012 7:33 PM, "Jack Krupansky" wrote: > If I understand correctly, SOLR-139, Support updateable/modifiable > documents, is in Solr 4.0, but the issue is still open pending further > enhancements. Since SOLR-139 is already in CHANGES.txt for 4.0, can I > suggest that the issue be closed and any further improvements be separate > issues to avoid confusion in CHANGES.txt? > > See: > https://issues.apache.org/jira/browse/SOLR-139 > > -- Jack Krupansky >
Status of SOLR-139 - Support updateable/modifiable documents
If I understand correctly, SOLR-139, Support updateable/modifiable documents, is in Solr 4.0, but the issue is still open pending further enhancements. Since SOLR-139 is already in CHANGES.txt for 4.0, can I suggest that the issue be closed and any further improvements be separate issues to avoid confusion in CHANGES.txt? See: https://issues.apache.org/jira/browse/SOLR-139 -- Jack Krupansky
[jira] [Commented] (SOLR-3304) Add Solr support for the new Lucene spatial module
[ https://issues.apache.org/jira/browse/SOLR-3304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502955#comment-13502955 ] Ari Maniatis commented on SOLR-3304: Early in this thread David Smiley listed a TODO item: "Document how to use it in the wiki". We are having considerable difficulty migrating from Solr 3.5 with SOLR-2155 to this new way of doing things. Any pointers to documentation for the new mechanism would be very much appreciated. > Add Solr support for the new Lucene spatial module > -- > > Key: SOLR-3304 > URL: https://issues.apache.org/jira/browse/SOLR-3304 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.0-ALPHA >Reporter: Bill Bell >Assignee: David Smiley >Priority: Critical > Labels: spatial > Fix For: 4.0 > > Attachments: SOLR-3304_Solr_fields_for_Lucene_spatial_module > (fieldName in Strategy) - indexableFields.patch, > SOLR-3304_Solr_fields_for_Lucene_spatial_module (fieldName in > Strategy).patch, SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, > SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, > SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, > SOLR-3304_Solr_fields_for_Lucene_spatial_module.patch, > SOLR-3304-strategy-getter-fixed.patch > > > Get the Solr spatial module integrated with the lucene spatial module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.8.0-ea-b58) - Build # 2733 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/2733/ Java: 64bit/jdk1.8.0-ea-b58 -XX:+UseParallelGC All tests passed Build Log: [...truncated 1217 lines...] [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: /mnt/ssd/jenkins/tools/java/64bit/jdk1.8.0-ea-b58/jre/bin/java -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/heapdumps -Dtests.prefix=tests -Dtests.seed=32FB1D090A4A -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.lockdir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build -Dtests.codec=random -Dtests.postingsformat=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=. -Dtests.sandbox.dir=/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core -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 -Dfile.encoding=US-ASCII -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.4.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/Ant/ANT_1.8.2/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/ivy-2.2.0.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-jdepend.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-netrexx.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-antlr.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-commons-net.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-javamail.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-regexp.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-jsch.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-junit4.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-jmf.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-junit.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-bcel.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-jai.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-commons-logging.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-resolver.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-oro.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-swing.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-bsf.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-apache-log4j.jar:/var/lib/jenkins/tools/Ant/ANT_1.8.2/lib/ant-testutil.jar:/mnt/ssd/jenkins/tools/java/64bit/jdk1.8.0-ea-b58/lib/tools.jar:/var/lib/jenkins/.ivy2/cache/com.carrotsearch.randomizedtesting/junit4-ant/jars/junit4-ant-2.0.4.jar -ea:org.apache.lucene... -ea:org.apache.solr... com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe -eventsfile /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/junit4-J0-20121122_213950_399.events @/mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build/core/test/junit4-J0-20121122_213950_399.suites [junit4:junit4] ERROR: JVM J0 ended with an exception: Forked process returned with error code: 134 Very likely a JVM crash. Process output piped in logs above. [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4.executeSlave(JUnit4.java:1206) [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4.access$000(JUnit4.java:65) [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4$2.call(JUnit4.java:813) [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4$2.call(JUnit4.java:810) [junit4:junit4] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [junit4:junit4] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) [junit4:junit4] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) [junit4:junit4] at java.lang.Thread.run(Thread.java:722) BU
[jira] [Commented] (SOLR-2816) Versioning
[ https://issues.apache.org/jira/browse/SOLR-2816?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502882#comment-13502882 ] Sami Siren commented on SOLR-2816: -- Seems like this is done. Or is there something left to do? > Versioning > -- > > Key: SOLR-2816 > URL: https://issues.apache.org/jira/browse/SOLR-2816 > Project: Solr > Issue Type: Sub-task > Components: SolrCloud, update >Reporter: Yonik Seeley > Fix For: 4.1 > > Attachments: SOLR-2816.patch > > > Adds and deletes need to be versioned by the leader so that this can be > relayed to all replicas for consistency (so an equivalent index can be built). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Fullmetal Jenkins: Solr4X - Build # 80 - Failure!
On Wed, Nov 21, 2012 at 6:46 AM, Mark Miller wrote: > > > Caused by: java.sql.SQLException: Supplied territory description > 'sr__#Latn' is invalid, expecting ln[_CO[_variant]] > > ln=lower-case two-letter ISO-639 language code, CO=upper-case two-letter > ISO-3166 country codes, see java.util.Locale. > This is wrong for even java7. So thats why Derby fails here: it cannot parse java7-style locales
Is the FunctionQuery API still experimental in 4.0?
I notice that FunctionQuery says “Note: This API is experimental and may change in non backward-compatible ways in the future”. Is this still true? I mean, sure, any of the APIs could change, but hasn’t FunctionQuery been relatively stable long enough to warrant removal of the “experimental” stigma? See: http://lucene.apache.org/core/4_0_0/queries/org/apache/lucene/queries/function/FunctionQuery.html -- Jack Krupansky
[jira] [Commented] (LUCENE-4570) release policeman tools?
[ https://issues.apache.org/jira/browse/LUCENE-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502842#comment-13502842 ] Dawid Weiss commented on LUCENE-4570: - +1 for making it reusable. It should be built into javac :) > release policeman tools? > > > Key: LUCENE-4570 > URL: https://issues.apache.org/jira/browse/LUCENE-4570 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Robert Muir > > Currently there is source code in lucene/tools/src (e.g. Forbidden APIs > checker ant task). > It would be convenient if you could download this thing in your ant build > from ivy (especially if maybe it included our definitions .txt files as > resources). > In general checking for locale/charset violations in this way is a pretty > general useful thing for a server-side app. > Can we either release lucene-tools.jar as an artifact, or maybe alternatively > move this somewhere else as a standalone project and suck it in ourselves? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4570) release policeman tools?
[ https://issues.apache.org/jira/browse/LUCENE-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502838#comment-13502838 ] Robert Muir commented on LUCENE-4570: - +1 for the blog post as documentation. Especially the portion in red text! > release policeman tools? > > > Key: LUCENE-4570 > URL: https://issues.apache.org/jira/browse/LUCENE-4570 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Robert Muir > > Currently there is source code in lucene/tools/src (e.g. Forbidden APIs > checker ant task). > It would be convenient if you could download this thing in your ant build > from ivy (especially if maybe it included our definitions .txt files as > resources). > In general checking for locale/charset violations in this way is a pretty > general useful thing for a server-side app. > Can we either release lucene-tools.jar as an artifact, or maybe alternatively > move this somewhere else as a standalone project and suck it in ourselves? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4570) release policeman tools?
[ https://issues.apache.org/jira/browse/LUCENE-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502837#comment-13502837 ] Uwe Schindler commented on LUCENE-4570: --- I think we should release the whole stuff, including parts of my blog post (http://blog.thetaphi.de/2012/07/default-locales-default-charsets-and.html) as documentation. The question is: Are there any restrictions from the Apache side by re-releasing source code (+ the TXT files) under a different name? I will go ahead already and add a ASF license header on top of our forbiddenApis/*.txt files! > release policeman tools? > > > Key: LUCENE-4570 > URL: https://issues.apache.org/jira/browse/LUCENE-4570 > Project: Lucene - Core > Issue Type: New Feature >Reporter: Robert Muir > > Currently there is source code in lucene/tools/src (e.g. Forbidden APIs > checker ant task). > It would be convenient if you could download this thing in your ant build > from ivy (especially if maybe it included our definitions .txt files as > resources). > In general checking for locale/charset violations in this way is a pretty > general useful thing for a server-side app. > Can we either release lucene-tools.jar as an artifact, or maybe alternatively > move this somewhere else as a standalone project and suck it in ourselves? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4570) release policeman tools?
Robert Muir created LUCENE-4570: --- Summary: release policeman tools? Key: LUCENE-4570 URL: https://issues.apache.org/jira/browse/LUCENE-4570 Project: Lucene - Core Issue Type: New Feature Reporter: Robert Muir Currently there is source code in lucene/tools/src (e.g. Forbidden APIs checker ant task). It would be convenient if you could download this thing in your ant build from ivy (especially if maybe it included our definitions .txt files as resources). In general checking for locale/charset violations in this way is a pretty general useful thing for a server-side app. Can we either release lucene-tools.jar as an artifact, or maybe alternatively move this somewhere else as a standalone project and suck it in ourselves? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2438) Case Insensitive Search for Wildcard Queries
[ https://issues.apache.org/jira/browse/SOLR-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502821#comment-13502821 ] Yonik Seeley commented on SOLR-2438: Thanks Karsten, I'll fold that change into my patch for SOLR-4093 > Case Insensitive Search for Wildcard Queries > > > Key: SOLR-2438 > URL: https://issues.apache.org/jira/browse/SOLR-2438 > Project: Solr > Issue Type: Improvement >Reporter: Peter Sturge >Assignee: Erick Erickson > Fix For: 3.6, 4.0-ALPHA > > Attachments: SOLR-2438_3x.patch, SOLR-2438-3x.patch, > SOLR-2438-3x.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch, > SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch, > SOLR-2438.patch, SOLR-2438.patch > > > This patch adds support to allow case-insensitive queries on wildcard > searches for configured TextField field types. > This patch extends the excellent work done Yonik and Michael in SOLR-219. > The approach here is different enough (imho) to warrant a separate JIRA issue. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4101) Provide a flag to store positions and offsets on fields defined in the schema
[ https://issues.apache.org/jira/browse/SOLR-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502818#comment-13502818 ] Yonik Seeley commented on SOLR-4101: +1 bq. storeOffsetsWithPositions' is a bit of a mouthful Yeah, but it's pretty descriptive of what it does (i.e. I won't need to go look up if it's referring to term vector offsets or not). bq. options = IndexOptions.DOCS_AND_FREQS_AND_POSITIONS_AND_OFFSETS; Now *that* is a mouthful ;-) micro-optimization: we should be able to throw an "else" before your "if", right? > Provide a flag to store positions and offsets on fields defined in the schema > - > > Key: SOLR-4101 > URL: https://issues.apache.org/jira/browse/SOLR-4101 > Project: Solr > Issue Type: Improvement >Reporter: Alan Woodward >Assignee: Alan Woodward >Priority: Minor > Fix For: 4.1, 5.0 > > Attachments: SOLR-4101.patch > > > This will be useful for highlighters (particularly ones based on interval > iterators, see LUCENE-2878) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2438) Case Insensitive Search for Wildcard Queries
[
https://issues.apache.org/jira/browse/SOLR-2438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502816#comment-13502816
]
Karsten R. commented on SOLR-2438:
--
Hi Erick,
in your commit Revision 1206767 (2011-11-27) there is a change in
org.apache.solr.search.SolrQueryParser#getReversedWildcardFilterFactory(FieldType)
Before this commit the Map leadingWildcards was important, after this the Map
leadingWildcards is only a cache. A cache, which is never used:
{code}
ReversedWildcardFilterFactory fac = leadingWildcards.get(fieldType);
if (fac == null && leadingWildcards.containsKey(fac)) {
return fac;
}
{code}
If we want to use this cache it should be
{code}
ReversedWildcardFilterFactory fac = leadingWildcards.get(fieldType);
if (fac != null || leadingWildcards.containsKey(fieldType)) {
return fac;
}
{code}
best regards
Karsten
> Case Insensitive Search for Wildcard Queries
>
>
> Key: SOLR-2438
> URL: https://issues.apache.org/jira/browse/SOLR-2438
> Project: Solr
> Issue Type: Improvement
>Reporter: Peter Sturge
>Assignee: Erick Erickson
> Fix For: 3.6, 4.0-ALPHA
>
> Attachments: SOLR-2438_3x.patch, SOLR-2438-3x.patch,
> SOLR-2438-3x.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch,
> SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch, SOLR-2438.patch,
> SOLR-2438.patch, SOLR-2438.patch
>
>
> This patch adds support to allow case-insensitive queries on wildcard
> searches for configured TextField field types.
> This patch extends the excellent work done Yonik and Michael in SOLR-219.
> The approach here is different enough (imho) to warrant a separate JIRA issue.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4258) Incremental Field Updates through Stacked Segments
[ https://issues.apache.org/jira/browse/LUCENE-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sivan Yogev updated LUCENE-4258: Attachment: (was: LUCENE-4258-inner-changes.patch) > Incremental Field Updates through Stacked Segments > -- > > Key: LUCENE-4258 > URL: https://issues.apache.org/jira/browse/LUCENE-4258 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Sivan Yogev > Attachments: IncrementalFieldUpdates.odp, > LUCENE-4258-API-changes.patch, LUCENE-4258.r1410593.patch, > LUCENE-4258.r1412262.patch > > Original Estimate: 2,520h > Remaining Estimate: 2,520h > > Shai and I would like to start working on the proposal to Incremental Field > Updates outlined here (http://markmail.org/message/zhrdxxpfk6qvdaex). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4258) Incremental Field Updates through Stacked Segments
[ https://issues.apache.org/jira/browse/LUCENE-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sivan Yogev updated LUCENE-4258: Attachment: LUCENE-4258.r1412262.patch New patch with additional testing and bug fixes. Currently the term statistics does not take into account field replacements, and therefore term counts are wrong and CheckIndex fails. I can think of two possible solutions for this. The first is for CheckIndex to identify updated segments and ignore term statistics - is there similar mechanism for deletions? The other solution is to pre-compute term statistics for updated segments. However, this will be costly - requires going through the entire posting list for every term, and count non-replaced occurrences. Any suggestions? > Incremental Field Updates through Stacked Segments > -- > > Key: LUCENE-4258 > URL: https://issues.apache.org/jira/browse/LUCENE-4258 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Sivan Yogev > Attachments: IncrementalFieldUpdates.odp, > LUCENE-4258-API-changes.patch, LUCENE-4258-inner-changes.patch, > LUCENE-4258.r1410593.patch, LUCENE-4258.r1412262.patch > > Original Estimate: 2,520h > Remaining Estimate: 2,520h > > Shai and I would like to start working on the proposal to Incremental Field > Updates outlined here (http://markmail.org/message/zhrdxxpfk6qvdaex). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4101) Provide a flag to store positions and offsets on fields defined in the schema
[
https://issues.apache.org/jira/browse/SOLR-4101?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502754#comment-13502754
]
Alan Woodward commented on SOLR-4101:
-
I plan on committing this tomorrow, unless anyone has better ideas for the flag
name ('storeOffsetsWithPositions' is a bit of a mouthful, but it needs to be
obviously different from TermVector offsets).
> Provide a flag to store positions and offsets on fields defined in the schema
> -
>
> Key: SOLR-4101
> URL: https://issues.apache.org/jira/browse/SOLR-4101
> Project: Solr
> Issue Type: Improvement
>Reporter: Alan Woodward
>Assignee: Alan Woodward
>Priority: Minor
> Fix For: 4.1, 5.0
>
> Attachments: SOLR-4101.patch
>
>
> This will be useful for highlighters (particularly ones based on interval
> iterators, see LUCENE-2878)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2141) NullPointerException when using escapeSql function
[ https://issues.apache.org/jira/browse/SOLR-2141?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502751#comment-13502751 ] Dominik Siebel commented on SOLR-2141: -- [~jdyer] Thanks, this seems to have fixed my problem. I'm currently doing a full import with a build from branch_4x, no NPEs, yet (at ~10% now). Sorry for the (maybe) dumb question, but: is there a gonna be a "stable" bugfix release or tag in the near future (not only for this issue, of course)? > NullPointerException when using escapeSql function > -- > > Key: SOLR-2141 > URL: https://issues.apache.org/jira/browse/SOLR-2141 > Project: Solr > Issue Type: Bug > Components: contrib - DataImportHandler >Affects Versions: 1.4.1 > Environment: openjdk 1.6.0 b12 >Reporter: Edward Rudd >Assignee: Koji Sekiguchi > Attachments: dih-config.xml, dih-file.xml, SOLR-2141.b341f5b.patch, > SOLR-2141.patch, SOLR-2141.patch, SOLR-2141-sample.patch, SOLR-2141-test.patch > > > I have two entities defined, nested in each other.. > > > > > Now, when I run that it bombs on any article where subcategory = '' (it's a > NOT NULL column so empty string is there) If i do where subcategory!='' in > the article query it works fine (aside from not pulling in all of the > articles). > org.apache.solr.handler.dataimport.DataImportHandlerException: > java.lang.NullPointerException > at > org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:424) > at > org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:383) > at > org.apache.solr.handler.dataimport.DocBuilder.doFullDump(DocBuilder.java:242) > at > org.apache.solr.handler.dataimport.DocBuilder.execute(DocBuilder.java:180) > at > org.apache.solr.handler.dataimport.DataImporter.doFullImport(DataImporter.java:331) > at > org.apache.solr.handler.dataimport.DataImporter.runCmd(DataImporter.java:389) > at > org.apache.solr.handler.dataimport.DataImporter$1.run(DataImporter.java:370) > Caused by: java.lang.NullPointerException > at > org.apache.solr.handler.dataimport.EvaluatorBag$1.evaluate(EvaluatorBag.java:75) > at > org.apache.solr.handler.dataimport.EvaluatorBag$5.get(EvaluatorBag.java:216) > at > org.apache.solr.handler.dataimport.EvaluatorBag$5.get(EvaluatorBag.java:204) > at > org.apache.solr.handler.dataimport.VariableResolverImpl.resolve(VariableResolverImpl.java:107) > at > org.apache.solr.handler.dataimport.TemplateString.fillTokens(TemplateString.java:81) > at > org.apache.solr.handler.dataimport.TemplateString.replaceTokens(TemplateString.java:75) > at > org.apache.solr.handler.dataimport.VariableResolverImpl.replaceTokens(VariableResolverImpl.java:87) > at > org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:71) > at > org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:237) > at > org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:357) > ... 6 more -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4258) Incremental Field Updates through Stacked Segments
[ https://issues.apache.org/jira/browse/LUCENE-4258?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sivan Yogev updated LUCENE-4258: Attachment: (was: LUCENE-4258.r1402630.patch) > Incremental Field Updates through Stacked Segments > -- > > Key: LUCENE-4258 > URL: https://issues.apache.org/jira/browse/LUCENE-4258 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Sivan Yogev > Attachments: IncrementalFieldUpdates.odp, > LUCENE-4258-API-changes.patch, LUCENE-4258-inner-changes.patch, > LUCENE-4258.r1410593.patch > > Original Estimate: 2,520h > Remaining Estimate: 2,520h > > Shai and I would like to start working on the proposal to Incremental Field > Updates outlined here (http://markmail.org/message/zhrdxxpfk6qvdaex). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4107) Parse Error message lost from 3.5.0 to 3.6.1
Pierre Gossé created SOLR-4107:
--
Summary: Parse Error message lost from 3.5.0 to 3.6.1
Key: SOLR-4107
URL: https://issues.apache.org/jira/browse/SOLR-4107
Project: Solr
Issue Type: Bug
Components: search
Affects Versions: 3.6.1
Reporter: Pierre Gossé
Priority: Minor
QueryComponent.prepare builds a SolrException from ParseException encountered,
using a constructor that forces error message to null
in 3.5.0
public SolrException(ErrorCode code, Throwable th) {
super(th);
this.code=code.code;
logged=true;
}
in 3.6.1 :
public SolrException(ErrorCode code, Throwable th) {
this(code, null, th, (th instanceof SolrException) ?
((SolrException)th).logged : false);
}
calling :
public SolrException(ErrorCode code, String msg, Throwable th, boolean
alreadyLogged) {
super(msg,th);
this.code=code.code;
logged=alreadyLogged;
}
I don't think this is a desired behaviour, so I guessed this should be
corrected by changing line 93 to
this(code, th.getMessage(), th, (th instanceof SolrException)
?(SolrException)th).logged : false);
I'll try to add a patch later today.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4047) dataimporter.functions.encodeUrl throughs Unable to encode expression: field.name with value: null
[
https://issues.apache.org/jira/browse/SOLR-4047?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502684#comment-13502684
]
Igor Dobritskiy commented on SOLR-4047:
---
Same issue with latest Trunk/5.x and branch_4x :(
Is there some documentation saying how to create unit tests for solr? I can at
least try to create unit test.
> dataimporter.functions.encodeUrl throughs Unable to encode expression:
> field.name with value: null
> --
>
> Key: SOLR-4047
> URL: https://issues.apache.org/jira/browse/SOLR-4047
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 4.0
> Environment: Windows 7
>Reporter: Igor Dobritskiy
>Priority: Critical
> Attachments: db-data-config.xml, db.sql, schema.xml, solrconfig.xml
>
>
> For some reason dataimporter.functions.encoude URL stopped work after update
> to solr 4.0 from 3.5.
> Here is the error
> {code}
> Full Import failed:java.lang.RuntimeException: java.lang.RuntimeException:
> org.apache.solr.handler.dataimport.DataImportHandlerException: Unable to
> encode expression: attach.name with value: null Processing Document # 1
> {code}
> Here is the data import config snippet:
> {code}
> ...
> query="select name from accounts where account_id =
> '${attach.account_id}'">
> dataSource="bin"
> format="text"
>
> url="http://example.com/data/${account.name}/attaches/${attach.item_id}/${dataimporter.functions.encodeUrl(attach.name)}">
>
>
>
> ...
> {code}
> When I'm changing it to *not* use dataimporter.functions.encodeUrl it works
> but I need to url encode file names as they have special chars in theirs
> names.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3993) SolrCloud leader election on single node stucks the initialization
[ https://issues.apache.org/jira/browse/SOLR-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13502672#comment-13502672 ] Werner Maier commented on SOLR-3993: To Po: (thanks for your comment) 1) [...]this only one core will be the leader finally. this will take a long time cause the waitForReplicasComeup() [...] I don't see a WaitForReplicasComeUp in the logs in that case. Maybe I missinterpreted the lots of exceptions in the log. After power fail or kill -9 it shows (for me) a recovery loop. Maybe this loop will end eventually (I stopped watching after some 10..15min). I'll try that again if I have some minutes. 2) Zookeeper: I know. But I'm a sysadmin dealing with real hardware (and failures) - not a programmer that just uses failure-free hardware and proposes preconditions :) I have seen a ROW of 19"-cabinets going down - even though each of them had TWO redundant Power Lines and the compunting center had a N+2 UPS. So I'm just trying all possible scenarios that I can imagine - and one of theese is a power outage for zookeeper and solr at the same time. Some things can be controlled with startup order (first zookeeper then solr) on single machines, but if multiple machines are involed, this gets difficult. If such a problem can easily circumvented by the solar instance reconnecting to the zookeeper, then the solr instance should just do that. So I tried these things and wrote the bug report - as maybe the developers (that do a very good job!) might just not have considered these cases. > SolrCloud leader election on single node stucks the initialization > -- > > Key: SOLR-3993 > URL: https://issues.apache.org/jira/browse/SOLR-3993 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.0 > Environment: Windows 7, Tomcat 6 >Reporter: Alexey Kudinov >Assignee: Mark Miller > Fix For: 4.1, 5.0 > > > setup: > 1 node, 4 cores, 2 shards. > 15 documents indexed. > problem: > init stage times out. > probable cause: > According to the init flow, cores are initialized one by one synchronously. > Actually, the main thread waits > ShardLeaderElectionContext.waitForReplicasToComeUp until retry threshold, > while replica cores are not yet initialized, in other words there is no > chance other replicas go up in the meanwhile. > stack trace: > Thread [main] (Suspended) > owns: HashMap (id=3876) > owns: StandardContext (id=3877) > owns: HashMap (id=3878) > owns: StandardHost (id=3879) > owns: StandardEngine (id=3880) > owns: Service[] (id=3881) > Thread.sleep(long) line: not available [native method] > ShardLeaderElectionContext.waitForReplicasToComeUp(boolean, String) > line: 298 > ShardLeaderElectionContext.runLeaderProcess(boolean) line: 143 > LeaderElector.runIamLeaderProcess(ElectionContext, boolean) line: 152 > LeaderElector.checkIfIamLeader(int, ElectionContext, boolean) line: 96 > LeaderElector.joinElection(ElectionContext) line: 262 > ZkController.joinElection(CoreDescriptor, boolean) line: 733 > ZkController.register(String, CoreDescriptor, boolean, boolean) line: > 566 > ZkController.register(String, CoreDescriptor) line: 532 > CoreContainer.registerInZk(SolrCore) line: 709 > CoreContainer.register(String, SolrCore, boolean) line: 693 > CoreContainer.load(String, InputSource) line: 535 > CoreContainer.load(String, File) line: 356 > CoreContainer$Initializer.initialize() line: 308 > SolrDispatchFilter.init(FilterConfig) line: 107 > ApplicationFilterConfig.getFilter() line: 295 > ApplicationFilterConfig.setFilterDef(FilterDef) line: 422 > ApplicationFilterConfig.(Context, FilterDef) line: 115 > StandardContext.filterStart() line: 4072 > StandardContext.start() line: 4726 > StandardHost(ContainerBase).addChildInternal(Container) line: 799 > StandardHost(ContainerBase).addChild(Container) line: 779 > StandardHost.addChild(Container) line: 601 > HostConfig.deployDescriptor(String, File, String) line: 675 > HostConfig.deployDescriptors(File, String[]) line: 601 > HostConfig.deployApps() line: 502 > HostConfig.start() line: 1317 > HostConfig.lifecycleEvent(LifecycleEvent) line: 324 > LifecycleSupport.fireLifecycleEvent(String, Object) line: 142 > StandardHost(ContainerBase).start() line: 1065 > StandardHost.start() line: 840 > StandardEngine(ContainerBase).start() line: 1057 > StandardEngine.start() line: 463 > StandardService.start() line: 525 > StandardServer.start(
Re: [JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.7.0_09) - Build # 1800 - Failure!
JVM error. Should we report these back to the hotspot folks? These seem like legitimate jit errors, not hardware-specific glitches. Dawid [junit4:junit4] >>> JVM J0: stdout (verbatim) [junit4:junit4] # [junit4:junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4:junit4] # [junit4:junit4] # Internal Error (assembler_x86.inline.hpp:46), pid=648, tid=2420 [junit4:junit4] # guarantee(this->is8bit(imm8)) failed: Short forward jump exceeds 8-bit offset [junit4:junit4] # [junit4:junit4] # JRE version: 7.0_09-b05 [junit4:junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (23.5-b02 mixed mode windows-amd64 compressed oops) [junit4:junit4] # Failed to write core dump. Minidumps are not enabled by default on client versions of Windows [junit4:junit4] # [junit4:junit4] # An error report file with more information is saved as: [junit4:junit4] # C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\core\test\J0\hs_err_pid648.log [junit4:junit4] # [junit4:junit4] # If you would like to submit a bug report, please visit: [junit4:junit4] # http://bugreport.sun.com/bugreport/crash.jsp [junit4:junit4] # [junit4:junit4] <<< JVM J0: EOF On Thu, Nov 22, 2012 at 10:10 AM, Policeman Jenkins Server wrote: > Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/1800/ > Java: 64bit/jdk1.7.0_09 -XX:+UseConcMarkSweepGC > > All tests passed > > Build Log: > [...truncated 798 lines...] > [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: > C:\Users\JenkinsSlave\tools\java\64bit\jdk1.7.0_09\jre\bin\java.exe > -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError > -XX:HeapDumpPath=C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\heapdumps > -Dtests.prefix=tests -Dtests.seed=6708A75925EBEDAC -Xmx512M -Dtests.iters= > -Dtests.verbose=false -Dtests.infostream=false > -Dtests.lockdir=C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build > -Dtests.codec=random -Dtests.postingsformat=random -Dtests.locale=random > -Dtests.timezone=random -Dtests.directory=random > -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=4.1 > -Dtests.cleanthreads=perMethod > -Djava.util.logging.config.file=C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\tools\junit4\logging.properties > -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true > -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. > -Djava.io.tmpdir=. > -Dtests.sandbox.dir=C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\core > > -Dclover.db.dir=C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\clover\db > -Djava.security.manager=org.apache.lucene.util.TestSecurityManager > -Djava.security.policy=C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene/tools/junit4/tests.policy > -Dlucene.version=4.1-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 > -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory > -Djava.awt.headless=true -classpath > C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\test-framework\classes\java;C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\codecs\classes\java;C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\test-framework\lib\junit-4.10.jar;C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\test-framework\lib\randomizedtesting-runner-2.0.4.jar;C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\core\classes\java;C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\core\classes\test;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-launcher.jar;C:\Users\JenkinsSlave\.ant\lib\ivy-2.2.0.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-antlr.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-bcel.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-bsf.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-log4j.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-oro.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-regexp.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-resolver.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-xalan2.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-commons-logging.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-commons-net.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-jai.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-javamail.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-jdepend.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-jmf.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-jsch.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-junit.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-junit4.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-netrexx.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-swing.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-tes
[JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.7.0_09) - Build # 1800 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/1800/ Java: 64bit/jdk1.7.0_09 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 798 lines...] [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: C:\Users\JenkinsSlave\tools\java\64bit\jdk1.7.0_09\jre\bin\java.exe -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\heapdumps -Dtests.prefix=tests -Dtests.seed=6708A75925EBEDAC -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.lockdir=C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build -Dtests.codec=random -Dtests.postingsformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=4.1 -Dtests.cleanthreads=perMethod -Djava.util.logging.config.file=C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\tools\junit4\logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. -Djava.io.tmpdir=. -Dtests.sandbox.dir=C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\core -Dclover.db.dir=C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\clover\db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene/tools/junit4/tests.policy -Dlucene.version=4.1-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -classpath C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\test-framework\classes\java;C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\codecs\classes\java;C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\test-framework\lib\junit-4.10.jar;C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\test-framework\lib\randomizedtesting-runner-2.0.4.jar;C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\core\classes\java;C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\core\classes\test;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-launcher.jar;C:\Users\JenkinsSlave\.ant\lib\ivy-2.2.0.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-antlr.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-bcel.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-bsf.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-log4j.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-oro.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-regexp.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-resolver.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-apache-xalan2.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-commons-logging.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-commons-net.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-jai.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-javamail.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-jdepend.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-jmf.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-jsch.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-junit.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-junit4.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-netrexx.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-swing.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant-testutil.jar;C:\Users\JenkinsSlave\tools\Ant\ANT_1.8.2\lib\ant.jar;C:\Users\JenkinsSlave\tools\java\64bit\jdk1.7.0_09\lib\tools.jar;C:\Users\JenkinsSlave\.ivy2\cache\com.carrotsearch.randomizedtesting\junit4-ant\jars\junit4-ant-2.0.4.jar -ea:org.apache.lucene... -ea:org.apache.solr... com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe -flush -eventsfile C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\core\test\junit4-J0-20121122_090540_788.events @C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\build\core\test\junit4-J0-20121122_090540_788.suites [junit4:junit4] ERROR: JVM J0 ended with an exception: Forked process returned with error code: 1 Very likely a JVM crash. Process output piped in logs above. [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4.executeSlave(JUnit4.java:1206) [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4.access$000(JUnit4.java:65) [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4$2.call(JUnit4.java:813) [junit4:junit4] at com.carrotsearch.ant.tasks.junit4.JUnit4$2.call(JUnit4.java:810) [junit4:junit4] at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) [junit4:junit4] at java.util.concurrent.FutureTask.run(FutureTask.java:166) [junit4:j
