[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 1147 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1147/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 10297 lines...] [junit4] JVM J0: stdout was not empty, see: /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/temp/junit4-J0-20131231_085921_675.sysout [junit4] JVM J0: stdout (verbatim) [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # SIGSEGV (0xb) at pc=0x00010b8bda20, pid=543, tid=220427 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18) [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode bsd-amd64 compressed oops) [junit4] # Problematic frame: [junit4] # C [libjava.dylib+0x9a20] JNU_NewStringPlatform+0x1c8 [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] # /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/J0/hs_err_pid543.log [junit4] # [junit4] # If you would like to submit a bug report, please visit: [junit4] # http://bugreport.sun.com/bugreport/crash.jsp [junit4] # The crash happened outside the Java Virtual Machine in native code. [junit4] # See problematic frame for where to report the bug. [junit4] # [junit4] JVM J0: EOF [...truncated 1 lines...] [junit4] ERROR: JVM J0 ended with an exception, command line: /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/bin/java -XX:+UseCompressedOops -XX:+UseParallelGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/heapdumps -Dtests.prefix=tests -Dtests.seed=35BAA8F77BD7A68 -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=4.7 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/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=. -Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/temp -Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/tests.policy -Dlucene.version=4.7-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 -classpath
[jira] [Commented] (SOLR-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859441#comment-13859441 ] Grant Ingersoll commented on SOLR-5507: --- +1, I have been thinking the same thing lately, as I found extending the current UI to be pretty hard to do when I added doc additions. Upayavira, might be nice to put up a patch, if you can. Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859442#comment-13859442 ] Grant Ingersoll commented on SOLR-5507: --- One of the things I would really love to see is the ability to plug in/inject new UI components. Imagine if we had a plugin framework that could ship the back-end functionality as well as the admin piece. After the plugin gets installed and registered, the admin piece slots in automatically. Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859445#comment-13859445 ] Upayavira commented on SOLR-5507: - I have a prototype of a complete rewrite, that shows the technology can create clean code even on something as complex as the analysis pane. However, I'm stalled on the topic of how to manage a transition between the two technologies, without requiring a hard-switch between them, as that would likely be way too tough to manage. So, we need to work out a way for the two technologies to play nicely together as an intermediate step - that's what I'm grappling with right now. Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859451#comment-13859451 ] Yago Riveiro commented on SOLR-5507: [~upayavira], What are the reasons for keeping the two UIs working together? I understand that rewrite the whole UI is a epic task, but the time that we will spend thinking and implementing a way to have the new and the old UI working together can be used to finish the new and release it with a new release of Solr. Also, in this transition, we will generate (most probably) new bugs and artefacts. With a point of time where we switch between both, all bugs will be about new UI. Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859456#comment-13859456 ] Grant Ingersoll commented on SOLR-5507: --- I see know reason to keep them working together. Do the new UI on trunk, leave the existing one on 4.x. We have no back compat requirements for UI, AFAIK. Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859461#comment-13859461 ] Upayavira commented on SOLR-5507: - There is a *lot* of code there. I have limited volunteer time. I could imagine it taking 3-6mths to get through it all. Open source development works best if the work can be done piecemeal, so we need to find a way to facilitate that, rather than getting 3/4 of the way through a 6mth project which then stalls through lack of developer time. Personally, I think this would be a fun project, that would benefit Solr. I'd love to see us find a way to make it happen. Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859463#comment-13859463 ] Upayavira commented on SOLR-5507: - The best way to keep something in development is to have something that is usable most of the time. If we crack that, then the transition between old and new is a set of simpler, small manageable steps, rather than a major project requiring planning/etc. Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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-5294) Suggester Dictionary implementation that takes expressions as term weights
[ https://issues.apache.org/jira/browse/LUCENE-5294?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859462#comment-13859462 ] ASF subversion and git services commented on LUCENE-5294: - Commit 1554409 from [~mikemccand] in branch 'dev/branches/lucene5376' [ https://svn.apache.org/r1554409 ] LUCENE-5294, LUCENE-5376: in Lucene demo server, support building suggester where weight is an expression Suggester Dictionary implementation that takes expressions as term weights -- Key: LUCENE-5294 URL: https://issues.apache.org/jira/browse/LUCENE-5294 Project: Lucene - Core Issue Type: New Feature Components: core/search Reporter: Areek Zillur Fix For: 4.6, 5.0 Attachments: LUCENE-5294.patch It would be nice to have a Suggester Dictionary implementation that could compute the weights of the terms consumed by the suggester based on an user-defined expression (using lucene's expression module). It could be an extension of the existing DocumentDictionary (which takes terms, weights and (optionally) payloads from the stored documents in the index). The only exception being that instead of taking the weights for the terms from the specified weight fields, it could compute the weights using an user-defn expression, that uses one or more NumicDocValuesField from the document. Example: let the document have - product_id - product_name - product_popularity - product_profit Then this implementation could be used with an expression of 0.2*product_popularity + 0.8*product_profit to determine the weights of the terms for the corresponding documents (optionally along with a payload (product_id)) -- 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=13859464#comment-13859464 ] ASF subversion and git services commented on LUCENE-5376: - Commit 1554409 from [~mikemccand] in branch 'dev/branches/lucene5376' [ https://svn.apache.org/r1554409 ] LUCENE-5294, LUCENE-5376: in Lucene demo server, support building suggester where weight is an expression 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] [Commented] (SOLR-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859465#comment-13859465 ] Yago Riveiro commented on SOLR-5507: Ok, seems a valid argument :D. If you release de code and some guide line about the architecture of the new UI, we can work in this new feature and see it in Solr soon. Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859466#comment-13859466 ] Upayavira commented on SOLR-5507: - I'll try to put some time aside this weekend to mess further. Either with a concurrent Sammy/Angular, or a pure Angular trunk version (which I've got going already, in a hacky way). Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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: JDK 7 Update 60 build 02 is available on java.net
Hi Rory, both preview builds (7u60-b02, 8-b121) were installed recently. The first built with JDK 8 b121 is already running: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8799/consoleFull 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: Saturday, December 28, 2013 10:41 PM To: dev@lucene.apache.org; rory.odonn...@oracle.com; 'Dawid Weiss' Cc: 'Dalibor Topic'; 'Cecilia Borg'; 'Balchandra Vaidya' Subject: RE: JDK 7 Update 60 build 02 is available on java.net Hi Rory, I will install this update (and also latest Java 8 build) during the next days. Currently I am out for vacation. Uwe - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de/ http://www.thetaphi.de eMail: mailto:u...@thetaphi.de u...@thetaphi.de From: Rory O'Donnell Oracle, Dublin Ireland [ mailto:rory.odonn...@oracle.com mailto:rory.odonn...@oracle.com] Sent: Friday, December 27, 2013 1:53 PM To: Uwe Schindler; Dawid Weiss Cc: mailto:dev@lucene.apache.org dev@lucene.apache.org; Dalibor Topic; Cecilia Borg; Balchandra Vaidya Subject: JDK 7 Update 60 build 02 is available on java.net Hi Uwe/Dawid, JDK 7u60 b02 Early Access Build is available for download https://jdk7.java.net/download.html test. Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
Re: JDK 7 Update 60 build 02 is available on java.net
Thanks Uwe! On 31/12/2013 12:49, Uwe Schindler wrote: Hi Rory, both preview builds (7u60-b02, 8-b121) were installed recently. The first built with JDK 8 b121 is already running: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/8799/consoleFull 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:* Saturday, December 28, 2013 10:41 PM *To:* dev@lucene.apache.org; rory.odonn...@oracle.com; 'Dawid Weiss' *Cc:* 'Dalibor Topic'; 'Cecilia Borg'; 'Balchandra Vaidya' *Subject:* RE: JDK 7 Update 60 build 02 is available on java.net Hi Rory, I will install this update (and also latest Java 8 build) during the next days. Currently I am out for vacation. Uwe - 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:*Rory O'Donnell Oracle, Dublin Ireland [mailto:rory.odonn...@oracle.com] *Sent:* Friday, December 27, 2013 1:53 PM *To:* Uwe Schindler; Dawid Weiss *Cc:* dev@lucene.apache.org mailto:dev@lucene.apache.org; Dalibor Topic; Cecilia Borg; Balchandra Vaidya *Subject:* JDK 7 Update 60 build 02 is available on java.net Hi Uwe/Dawid, JDK 7u60 b02 Early Access Build is available for download https://jdk7.java.net/download.html test. Rgds,Rory -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland -- Rgds,Rory O'Donnell Quality Engineering Manager Oracle EMEA , Dublin, Ireland
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859480#comment-13859480 ] rashi gandhi commented on LUCENE-2899: -- ok, thanks Lance. One more Queation I want to design an analyzer that can support location containment relationship , For example Europe-France-Paris My requirement is like: when user search for any country , then results must have the documents having that country , as well as the documents having states and cities which comes under that country. But , documents with country name must have high relevancy. It must obeys containment relationship up to 4 levels .i.e. Continent-Country-State-City I wanted to know , is there any way in OpenNLP that can support this type of search. Can location tagger model can be used for this? Please provide me some pointers to move ahead Thanks in Advance Add OpenNLP Analysis capabilities as a module - Key: LUCENE-2899 URL: https://issues.apache.org/jira/browse/LUCENE-2899 Project: Lucene - Core Issue Type: New Feature Components: modules/analysis Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 4.7 Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, OpenNLPFilter.java, OpenNLPTokenizer.java Now that OpenNLP is an ASF project and has a nice license, it would be nice to have a submodule (under analysis) that exposed capabilities for it. Drew Farris, Tom Morton and I have code that does: * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it would have to change slightly to buffer tokens) * NamedEntity recognition as a TokenFilter We are also planning a Tokenizer/TokenFilter that can put parts of speech as either payloads (PartOfSpeechAttribute?) on a token or at the same position. I'd propose it go under: modules/analysis/opennlp -- This message 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-2899) Add OpenNLP Analysis capabilities as a module
[ https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859480#comment-13859480 ] rashi gandhi edited comment on LUCENE-2899 at 12/31/13 1:07 PM: ok, thanks Lance. One more Question I wanted to design an analyzer that can support location containment relationship , For example Europe-France-Paris My requirement is like: when user search for any country , then results must have the documents having that country , as well as the documents having states and cities which comes under that country. But , documents with country name must have high relevancy. It must obeys containment relationship up to 4 levels .i.e. Continent-Country-State-City I wanted to know , is there any way in OpenNLP that can support this type of search. Can location tagger model can be used for this? Please provide me some pointers to move ahead Thanks in Advance was (Author: rashi): ok, thanks Lance. One more Queation I want to design an analyzer that can support location containment relationship , For example Europe-France-Paris My requirement is like: when user search for any country , then results must have the documents having that country , as well as the documents having states and cities which comes under that country. But , documents with country name must have high relevancy. It must obeys containment relationship up to 4 levels .i.e. Continent-Country-State-City I wanted to know , is there any way in OpenNLP that can support this type of search. Can location tagger model can be used for this? Please provide me some pointers to move ahead Thanks in Advance Add OpenNLP Analysis capabilities as a module - Key: LUCENE-2899 URL: https://issues.apache.org/jira/browse/LUCENE-2899 Project: Lucene - Core Issue Type: New Feature Components: modules/analysis Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 4.7 Attachments: LUCENE-2899-RJN.patch, LUCENE-2899.patch, OpenNLPFilter.java, OpenNLPTokenizer.java Now that OpenNLP is an ASF project and has a nice license, it would be nice to have a submodule (under analysis) that exposed capabilities for it. Drew Farris, Tom Morton and I have code that does: * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it would have to change slightly to buffer tokens) * NamedEntity recognition as a TokenFilter We are also planning a Tokenizer/TokenFilter that can put parts of speech as either payloads (PartOfSpeechAttribute?) on a token or at the same position. I'd propose it go under: modules/analysis/opennlp -- This message 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-5536) Add ValueSource collapse criteria to CollapsingQParsingPlugin
[
https://issues.apache.org/jira/browse/SOLR-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859501#comment-13859501
]
ASF subversion and git services commented on SOLR-5536:
---
Commit 1554523 from [~joel.bernstein] in branch 'dev/trunk'
[ https://svn.apache.org/r1554523 ]
SOLR-5536: Add ValueSource collapse criteria to CollapsingQParserPlugin
Add ValueSource collapse criteria to CollapsingQParsingPlugin
-
Key: SOLR-5536
URL: https://issues.apache.org/jira/browse/SOLR-5536
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 4.6
Reporter: Joel Bernstein
Assignee: Joel Bernstein
Priority: Minor
Fix For: 5.0, 4.7
Attachments: SOLR-5536.patch, SOLR-5536.patch, SOLR-5536.patch,
SOLR-5536.patch
It would be useful for the CollapsingQParserPlugin to support ValueSource
collapse criteria.
Proposed syntax:
{code}
fq={!collapse field=collapse_field max=value_source}
{code}
This ticket will also introduce a function query called cscore, which will
return the score of the current document being collapsed. This will allow
score to be incorporated into collapse criteria functions.
A simple example of the cscore usage:
{code}
fq={!collapse field=collapse_field max=sum(cscore(), field(x))}
{code}
--
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-5474) Have a new mode for SolrJ to not watch any ZKNode
[ https://issues.apache.org/jira/browse/SOLR-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter updated SOLR-5474: - Attachment: SOLR-5474.patch Here's the start of a solution for this ticket. This first patch contains a LazyCloudSolrServer implementation + unit tests and changes to ZkStateReader to not watch any znodes. More functional unit tests are needed as is some chaos monkey type tests to verify that the lazy approach can respond to all possible cluster state changes correctly. Have a new mode for SolrJ to not watch any ZKNode - Key: SOLR-5474 URL: https://issues.apache.org/jira/browse/SOLR-5474 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Attachments: SOLR-5474.patch In this mode SolrJ would not watch any ZK node It fetches the state on demand and cache the most recently used n collections in memory. SolrJ would not listen to any ZK node. When a request comes for a collection ‘xcoll’ it would first check if such a collection exists If yes it first looks up the details in the local cache for that collection If not found in cache , it fetches the node /collections/xcoll/state.json and caches the information Any query/update will be sent with extra query param specifying the collection name , shard name, Role (Leader/Replica), and range (example \_target_=xcoll:shard1:L:8000-b332) . A node would throw an error (INVALID_NODE) if it does not the serve the collection/shard/Role/range combo. If SolrJ gets INVALID_NODE error it would invalidate the cache and fetch fresh state information for that collection (and caches it again) If there is a connection timeout, SolrJ assumes the node is down and re-fetch the state for the collection and try again -- 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-5536) Add ValueSource collapse criteria to CollapsingQParsingPlugin
[
https://issues.apache.org/jira/browse/SOLR-5536?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859525#comment-13859525
]
ASF subversion and git services commented on SOLR-5536:
---
Commit 1554537 from [~joel.bernstein] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1554537 ]
SOLR-5536: Add ValueSource collapse criteria to CollapsingQParserPlugin
Add ValueSource collapse criteria to CollapsingQParsingPlugin
-
Key: SOLR-5536
URL: https://issues.apache.org/jira/browse/SOLR-5536
Project: Solr
Issue Type: Improvement
Components: search
Affects Versions: 4.6
Reporter: Joel Bernstein
Assignee: Joel Bernstein
Priority: Minor
Fix For: 5.0, 4.7
Attachments: SOLR-5536.patch, SOLR-5536.patch, SOLR-5536.patch,
SOLR-5536.patch
It would be useful for the CollapsingQParserPlugin to support ValueSource
collapse criteria.
Proposed syntax:
{code}
fq={!collapse field=collapse_field max=value_source}
{code}
This ticket will also introduce a function query called cscore, which will
return the score of the current document being collapsed. This will allow
score to be incorporated into collapse criteria functions.
A simple example of the cscore usage:
{code}
fq={!collapse field=collapse_field max=sum(cscore(), field(x))}
{code}
--
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-1578) Develop a Spatial Query Parser
[ https://issues.apache.org/jira/browse/SOLR-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859534#comment-13859534 ] Furkan KAMACI commented on SOLR-1578: - Hi; What are the requirement here? I have read that article: http://www.ibm.com/developerworks/java/library/j-spatial/index.html written by [~gsingers] and if we can explain the requirements I can develop a patch for this issue. Develop a Spatial Query Parser -- Key: SOLR-1578 URL: https://issues.apache.org/jira/browse/SOLR-1578 Project: Solr Issue Type: New Feature Components: spatial Reporter: Grant Ingersoll Given all the work around spatial, it would be beneficial if Solr had a query parser for dealing with spatial queries. For starters, something that used geonames data or maybe even Google Maps API would be really useful. Longer term, a spatial grammar that can robustly handle all the vagaries of addresses, etc. would be really cool. Refs: [1] http://www.geonames.org/export/client-libraries.html (note the Java client is ASL) [2] Data from geo names: http://download.geonames.org/export/dump/ -- 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-5593) shard leader loss due to ZK session expiry
Christine Poerschke created SOLR-5593: - Summary: shard leader loss due to ZK session expiry Key: SOLR-5593 URL: https://issues.apache.org/jira/browse/SOLR-5593 Project: Solr Issue Type: Improvement Reporter: Christine Poerschke The problem we saw was that the shard leader ceased to be shard leader (in our case due to its zookeeper session expiring). The followers thus rejected update requests (DistributedUpdateProcessor setupRequest's call to ZkStateReader getLeaderRetry) and the leader asked them to recover (DistributedUpdateProcessor doFinish). The followers published themselves as recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard leader loss triggered an election in which none of the followers became the leader due to their recovering state (ShardLeaderElectionContext shouldIBeLeader). The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). -- 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-5593) shard leader loss due to ZK session expiry
[ https://issues.apache.org/jira/browse/SOLR-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Christine Poerschke updated SOLR-5593: -- Attachment: CoreAdminHandler.patch Attaching one potential solution (we are investigating others): As part of the recovery process state=recovering publishing already happens (RecoveryStrategy doRecovery) but only after a shard leader to recover from has been found. If the CoreAdminHandler handleRequestRecoveryAction publish had not happened then one of the followers should have been elected shard leader. shard leader loss due to ZK session expiry -- Key: SOLR-5593 URL: https://issues.apache.org/jira/browse/SOLR-5593 Project: Solr Issue Type: Improvement Reporter: Christine Poerschke Attachments: CoreAdminHandler.patch The problem we saw was that the shard leader ceased to be shard leader (in our case due to its zookeeper session expiring). The followers thus rejected update requests (DistributedUpdateProcessor setupRequest's call to ZkStateReader getLeaderRetry) and the leader asked them to recover (DistributedUpdateProcessor doFinish). The followers published themselves as recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard leader loss triggered an election in which none of the followers became the leader due to their recovering state (ShardLeaderElectionContext shouldIBeLeader). The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). -- 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] [Moved] (SOLR-5594) Enable using extended field types with prefix queries for non-default encoded strings
[ https://issues.apache.org/jira/browse/SOLR-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man moved LUCENE-5378 to SOLR-5594: Component/s: (was: core/queryparser) Schema and Analysis query parsers Lucene Fields: (was: New) Affects Version/s: (was: 4.6) 4.6 Key: SOLR-5594 (was: LUCENE-5378) Project: Solr (was: Lucene - Core) Enable using extended field types with prefix queries for non-default encoded strings - Key: SOLR-5594 URL: https://issues.apache.org/jira/browse/SOLR-5594 Project: Solr Issue Type: Improvement Components: query parsers, Schema and Analysis Affects Versions: 4.6 Reporter: Anshum Gupta Priority: Minor Enable users to be able to use prefix query with custom field types with non-default encoding/decoding for queries more easily. e.g. having a custom field work with base64 encoded query strings. Currently, the workaround for it is to have the override at getRewriteMethod level. Perhaps having the prefixQuery also use the calling FieldType's readableToIndexed method would work better. -- 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-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859549#comment-13859549 ] Hoss Man commented on SOLR-5507: bq. I see know reason to keep them working together. Do the new UI on trunk, leave the existing one on 4.x. We have no back compat requirements for UI, AFAIK. But the best way to help find bugs in the new UI, and to encourage people to help add features, is to get it in the hands of users in releases. What we did with the current UI during the 3.x/4.x time frame was to have both UI code bases going under diff paths -- the old JSP based UI used /admin while the new UI just used / ... you could do the same thing with an angular based UI, pick any path (maybe even /experimental_ui and anchor the new work there - commit to both trunk and the 4x branch, and start publicizing it to new users even in the 4.x releases. if it takes off, and people like it then we eventually update trunk to mv /experimental_ui to / and remove the current stuff Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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] [Assigned] (SOLR-5593) shard leader loss due to ZK session expiry
[ https://issues.apache.org/jira/browse/SOLR-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller reassigned SOLR-5593: - Assignee: Mark Miller shard leader loss due to ZK session expiry -- Key: SOLR-5593 URL: https://issues.apache.org/jira/browse/SOLR-5593 Project: Solr Issue Type: Improvement Reporter: Christine Poerschke Assignee: Mark Miller Attachments: CoreAdminHandler.patch The problem we saw was that the shard leader ceased to be shard leader (in our case due to its zookeeper session expiring). The followers thus rejected update requests (DistributedUpdateProcessor setupRequest's call to ZkStateReader getLeaderRetry) and the leader asked them to recover (DistributedUpdateProcessor doFinish). The followers published themselves as recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard leader loss triggered an election in which none of the followers became the leader due to their recovering state (ShardLeaderElectionContext shouldIBeLeader). The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). -- 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-5593) shard leader loss due to ZK session expiry
[ https://issues.apache.org/jira/browse/SOLR-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859557#comment-13859557 ] Mark Miller commented on SOLR-5593: --- Great find! bq. The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). This I'm surprised to see - when someone cannot be the leader, for instance if they published a non active state last, they should get back in line - the original leader should have his chance again... shard leader loss due to ZK session expiry -- Key: SOLR-5593 URL: https://issues.apache.org/jira/browse/SOLR-5593 Project: Solr Issue Type: Improvement Reporter: Christine Poerschke Attachments: CoreAdminHandler.patch The problem we saw was that the shard leader ceased to be shard leader (in our case due to its zookeeper session expiring). The followers thus rejected update requests (DistributedUpdateProcessor setupRequest's call to ZkStateReader getLeaderRetry) and the leader asked them to recover (DistributedUpdateProcessor doFinish). The followers published themselves as recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard leader loss triggered an election in which none of the followers became the leader due to their recovering state (ShardLeaderElectionContext shouldIBeLeader). The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). -- 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-5593) shard leader loss due to ZK session expiry
[ https://issues.apache.org/jira/browse/SOLR-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859562#comment-13859562 ] Mark Miller commented on SOLR-5593: --- I think your change is probably good in general. Let's see what else we can do here. One thing that seems kind of silly is that those replicas reject the updates at all. It seems like perhaps we should relax things a bit so that they would be accepted. shard leader loss due to ZK session expiry -- Key: SOLR-5593 URL: https://issues.apache.org/jira/browse/SOLR-5593 Project: Solr Issue Type: Improvement Reporter: Christine Poerschke Assignee: Mark Miller Attachments: CoreAdminHandler.patch The problem we saw was that the shard leader ceased to be shard leader (in our case due to its zookeeper session expiring). The followers thus rejected update requests (DistributedUpdateProcessor setupRequest's call to ZkStateReader getLeaderRetry) and the leader asked them to recover (DistributedUpdateProcessor doFinish). The followers published themselves as recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard leader loss triggered an election in which none of the followers became the leader due to their recovering state (ShardLeaderElectionContext shouldIBeLeader). The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). -- 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-5593) shard leader loss due to ZK session expiry
[ https://issues.apache.org/jira/browse/SOLR-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5593: -- Component/s: SolrCloud Fix Version/s: 4.6.1 5.0 4.6 Issue Type: Bug (was: Improvement) shard leader loss due to ZK session expiry -- Key: SOLR-5593 URL: https://issues.apache.org/jira/browse/SOLR-5593 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Christine Poerschke Assignee: Mark Miller Fix For: 4.6, 5.0, 4.6.1 Attachments: CoreAdminHandler.patch The problem we saw was that the shard leader ceased to be shard leader (in our case due to its zookeeper session expiring). The followers thus rejected update requests (DistributedUpdateProcessor setupRequest's call to ZkStateReader getLeaderRetry) and the leader asked them to recover (DistributedUpdateProcessor doFinish). The followers published themselves as recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard leader loss triggered an election in which none of the followers became the leader due to their recovering state (ShardLeaderElectionContext shouldIBeLeader). The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). -- 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-5593) shard leader loss due to ZK session expiry
[ https://issues.apache.org/jira/browse/SOLR-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5593: -- Fix Version/s: (was: 4.6) 4.7 shard leader loss due to ZK session expiry -- Key: SOLR-5593 URL: https://issues.apache.org/jira/browse/SOLR-5593 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Christine Poerschke Assignee: Mark Miller Fix For: 5.0, 4.7, 4.6.1 Attachments: CoreAdminHandler.patch The problem we saw was that the shard leader ceased to be shard leader (in our case due to its zookeeper session expiring). The followers thus rejected update requests (DistributedUpdateProcessor setupRequest's call to ZkStateReader getLeaderRetry) and the leader asked them to recover (DistributedUpdateProcessor doFinish). The followers published themselves as recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard leader loss triggered an election in which none of the followers became the leader due to their recovering state (ShardLeaderElectionContext shouldIBeLeader). The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). -- 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-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859566#comment-13859566 ] Upayavira commented on SOLR-5507: - Hoss - that could work - so long as folks do new feature development on both, or on the new one only. I'll try and come up with a patch to get this started. Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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] [Assigned] (SOLR-5594) Enable using extended field types with prefix queries for non-default encoded strings
[ https://issues.apache.org/jira/browse/SOLR-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta reassigned SOLR-5594: -- Assignee: Anshum Gupta Enable using extended field types with prefix queries for non-default encoded strings - Key: SOLR-5594 URL: https://issues.apache.org/jira/browse/SOLR-5594 Project: Solr Issue Type: Improvement Components: query parsers, Schema and Analysis Affects Versions: 4.6 Reporter: Anshum Gupta Assignee: Anshum Gupta Priority: Minor Attachments: SOLR-5594.patch Enable users to be able to use prefix query with custom field types with non-default encoding/decoding for queries more easily. e.g. having a custom field work with base64 encoded query strings. Currently, the workaround for it is to have the override at getRewriteMethod level. Perhaps having the prefixQuery also use the calling FieldType's readableToIndexed method would work better. -- 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-5594) Enable using extended field types with prefix queries for non-default encoded strings
[ https://issues.apache.org/jira/browse/SOLR-5594?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-5594: --- Attachment: SOLR-5594.patch Sans the test. Working on the tests right now. Enable using extended field types with prefix queries for non-default encoded strings - Key: SOLR-5594 URL: https://issues.apache.org/jira/browse/SOLR-5594 Project: Solr Issue Type: Improvement Components: query parsers, Schema and Analysis Affects Versions: 4.6 Reporter: Anshum Gupta Priority: Minor Attachments: SOLR-5594.patch Enable users to be able to use prefix query with custom field types with non-default encoding/decoding for queries more easily. e.g. having a custom field work with base64 encoded query strings. Currently, the workaround for it is to have the override at getRewriteMethod level. Perhaps having the prefixQuery also use the calling FieldType's readableToIndexed method would work better. -- 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-5593) shard leader loss due to ZK session expiry
[ https://issues.apache.org/jira/browse/SOLR-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859600#comment-13859600 ] Christine Poerschke commented on SOLR-5593: --- bq. One thing that seems kind of silly is that those replicas reject the updates at all. It seems like perhaps we should relax things a bit so that they would be accepted. Yes, we are working on changes to DistributedUpdateProcessor to relax the requirement for the getLeaderRetry to succeed within setupRequest (if phase is DistribPhase.FROMLEADER and the shard state shows it could not be subShardLeader then getLeaderRetry success should be optional). shard leader loss due to ZK session expiry -- Key: SOLR-5593 URL: https://issues.apache.org/jira/browse/SOLR-5593 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Christine Poerschke Assignee: Mark Miller Fix For: 5.0, 4.7, 4.6.1 Attachments: CoreAdminHandler.patch The problem we saw was that the shard leader ceased to be shard leader (in our case due to its zookeeper session expiring). The followers thus rejected update requests (DistributedUpdateProcessor setupRequest's call to ZkStateReader getLeaderRetry) and the leader asked them to recover (DistributedUpdateProcessor doFinish). The followers published themselves as recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard leader loss triggered an election in which none of the followers became the leader due to their recovering state (ShardLeaderElectionContext shouldIBeLeader). The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). -- 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-5595) Distributed Sort: potential performance improvements code readabiliity
Hoss Man created SOLR-5595: -- Summary: Distributed Sort: potential performance improvements code readabiliity Key: SOLR-5595 URL: https://issues.apache.org/jira/browse/SOLR-5595 Project: Solr Issue Type: Improvement Reporter: Hoss Man A lot of the work solr currently does for dealing with distributed sorting was built based on older limitations in Lucene that no longer exist. There are opportunities to simplify the code significantly, which should result in a speed up -- the biggest blocker at this point is some caching related questions. I'll post my specific thoughts in a comment (This is inspired by some things I noticed working on SOLR-5463 - I didn't want to convolute that issue with these performance improvement ideas which could be dealt with separately) -- 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-5595) Distributed Sort: potential performance improvements code readabiliity
[
https://issues.apache.org/jira/browse/SOLR-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859610#comment-13859610
]
Hoss Man commented on SOLR-5595:
Based on my understanding of the code, there are 3 major (overlapping) changes
that could be made to help improve/clarify solr's distributed sorting code:
1) leveraging fillFields
The basic premise behind all of the work done in QueryComponent's
doFieldSortValues method is summarized in this comment at the top of the
method...
{noformat}
// The query cache doesn't currently store sort field values, and
SolrIndexSearcher doesn't
// currently have an option to return sort field values. Because of this, we
// take the documents given and re-derive the sort values.
{noformat}
While the query cache issue is certainly still true, improvements at the
IndexSearcher level now make it possible to request that the TopDocCollector
also record the sort values for each doc it collects -- these are available in
the FieldDoc objects returned.
SOLR-5463 is already taking avantage of this feature for cursor based searching
-- but that also bypasses the cache (for a variety of reasons). if we enhance
the query reesult cache to also preserve the sort values for each doc in the
DocList, then the same fillFields feature could be used to pull back all of
the sort values.
This would pretty much completely eliminate the need for 90% of the work
currently done in doFieldSortValues -- and should be much faster since we'll be
re-using the sort values already generated during the actual sorting, we won't
need to hit the index again to re-derive them.
2) Let fillFields provide the score if needed for sorting
Assuming we start using IndexSearcher's fillField option, then we could
probably simplify some of the logic in QueryComponent regarding sorting by
score. doFieldSortValues currently can't generate the score, so the
coordinator has to ask for it explicitly in the fl so it can be used with
merging. These special edge cases could probably be removed, and the scores
would come back along with the other sort values.
3) eliminate ShardDoc.sortFieldValues and use FieldDoc.fields
When a node is coordinating a distributed request, QueryComponent.mergeIds
collects the docs returned by each shard into ShardDoc objects which have a
sortFieldValues property containing the full list of all sort values (of all
docs returned by that shard) tacked on to it in a convoluted nested structure
that makes very little sense when looking at the code. But ShardDoc already
extends FieldDoc which has a fields array designed to store the sort fields.
If mergeIds just populated the fields of each ShardDoc based on the
sort_values returned from the shard, then the mergeIds method could be a lot
simplier and the code would be a lot clearer to read. It should also be
possible to eliminate most/all of ShardFieldSortedHitQueue and instead leverage
the logic in FieldValueHitQueue directly.
Distributed Sort: potential performance improvements code readabiliity
Key: SOLR-5595
URL: https://issues.apache.org/jira/browse/SOLR-5595
Project: Solr
Issue Type: Improvement
Reporter: Hoss Man
A lot of the work solr currently does for dealing with distributed sorting
was built based on older limitations in Lucene that no longer exist. There
are opportunities to simplify the code significantly, which should result in
a speed up -- the biggest blocker at this point is some caching related
questions.
I'll post my specific thoughts in a comment
(This is inspired by some things I noticed working on SOLR-5463 - I didn't
want to convolute that issue with these performance improvement ideas which
could be dealt with separately)
--
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-5595) Distributed Sort: potential performance improvements code readabiliity
[ https://issues.apache.org/jira/browse/SOLR-5595?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859611#comment-13859611 ] Hoss Man commented on SOLR-5595: The initial change that would be needed to explore any of these ideas is addressing the issue of the query result cache. It seems like adding a FieldDoc[] onto the DocSlice should be fairly straight forward, even when dealing with the subset and cache window stuff -- but for non trivial sorts it would likely result in a significant change to the memory foot print, which could be very annoying if you aren't using distributed sorting. my off the cuff suggestion would be: * change the code to include the FieldDoc (sort values) in the (cached) DocSlices * add an explicit option to disable caching of the sort values (for single node users) * make distributed searching fail hard if that explicit option is set ** fail hard on SolrCore init in cloud mode ** fail hard at request time if it's an older style shards=... distributed request. Distributed Sort: potential performance improvements code readabiliity Key: SOLR-5595 URL: https://issues.apache.org/jira/browse/SOLR-5595 Project: Solr Issue Type: Improvement Reporter: Hoss Man A lot of the work solr currently does for dealing with distributed sorting was built based on older limitations in Lucene that no longer exist. There are opportunities to simplify the code significantly, which should result in a speed up -- the biggest blocker at this point is some caching related questions. I'll post my specific thoughts in a comment (This is inspired by some things I noticed working on SOLR-5463 - I didn't want to convolute that issue with these performance improvement ideas which could be dealt with separately) -- 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-1578) Develop a Spatial Query Parser
[ https://issues.apache.org/jira/browse/SOLR-1578?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-1578. Resolution: Duplicate I'm closing this as a duplicate of SOLR-4242. This issue came first but I think there is better context/discussion there. Develop a Spatial Query Parser -- Key: SOLR-1578 URL: https://issues.apache.org/jira/browse/SOLR-1578 Project: Solr Issue Type: New Feature Components: spatial Reporter: Grant Ingersoll Given all the work around spatial, it would be beneficial if Solr had a query parser for dealing with spatial queries. For starters, something that used geonames data or maybe even Google Maps API would be really useful. Longer term, a spatial grammar that can robustly handle all the vagaries of addresses, etc. would be really cool. Refs: [1] http://www.geonames.org/export/client-libraries.html (note the Java client is ASL) [2] Data from geo names: http://download.geonames.org/export/dump/ -- 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-4242) A better spatial query parser
[
https://issues.apache.org/jira/browse/SOLR-4242?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859647#comment-13859647
]
David Smiley commented on SOLR-4242:
Just a small update to this issue. Spatial4j 0.4 is nearly done, and it has
it's own WKT parser. That makes it easier to have a Solr spatial query parser
that reads WKT without inadvertent dependencies on JTS which isn't (and can't
be) shipped with Solr.
My curent thinking is to simply add a new wkt param that is read by
\{!geofilt\} geodist() which they could use in the absence of pt being
specified. The main annoyance I have with the situation is that the current
query parser geofilt suggest *geo*spatial (i.e. geodetic) and not a
Euclidean/Cartesian flat plane model. So might there be a new \{!sfilt\} and
sdist()? But dist() already exists and has strange args. I wish all these
things were thought out in advance before the existing names were chosen
because as Solr compatibility goes, it's all on stone tablets for generations
to come now. Something can be worked out though.
A better spatial query parser
-
Key: SOLR-4242
URL: https://issues.apache.org/jira/browse/SOLR-4242
Project: Solr
Issue Type: New Feature
Components: spatial
Reporter: David Smiley
Fix For: 4.6
I've been thinking about how spatial support is exposed to Solr users.
Presently there's the older Solr 3 stuff, most prominently seen via
\{!geofilt} and \{!bbox} done by [~gsingers] (I think). and then there's the
Solr 4 fields using a special syntax parsed by Lucene 4 spatial that looks
like mygeofield:Intersects(Circle(1 2 d=3)) What's inside the outer
parenthesis is parsed by Spatial4j as a shape, and it has a special
(non-standard) syntax for points, rects, and circles, and then there's WKT.
I believe this scheme was devised by [~ryantxu].
I'd like to devise something that is both comprehensive and is aligned with
standards to the extent that it's prudent. The old Solr 3 stuff is not
comprehensive and not standardized. The newer stuff is comprehensive but
only a little based on standards. And I think it'd be nicer to implement it
as a Solr query parser. I'll say more in the comments.
--
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] [Assigned] (SOLR-5593) shard leader loss due to ZK session expiry
[ https://issues.apache.org/jira/browse/SOLR-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe reassigned SOLR-5593: Assignee: Steve Rowe (was: Mark Miller) shard leader loss due to ZK session expiry -- Key: SOLR-5593 URL: https://issues.apache.org/jira/browse/SOLR-5593 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Christine Poerschke Assignee: Steve Rowe Fix For: 5.0, 4.7, 4.6.1 Attachments: CoreAdminHandler.patch The problem we saw was that the shard leader ceased to be shard leader (in our case due to its zookeeper session expiring). The followers thus rejected update requests (DistributedUpdateProcessor setupRequest's call to ZkStateReader getLeaderRetry) and the leader asked them to recover (DistributedUpdateProcessor doFinish). The followers published themselves as recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard leader loss triggered an election in which none of the followers became the leader due to their recovering state (ShardLeaderElectionContext shouldIBeLeader). The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). -- 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-trunk-Linux-Java7-64-test-only - Build # 72345 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/72345/ No tests ran. Build Log: [...truncated 12 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[JENKINS] Lucene-4x-Linux-Java6-64-test-only - Build # 8666 - Failure!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java6-64-test-only/8666/ No tests ran. Build Log: [...truncated 11 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[jira] [Assigned] (SOLR-5593) shard leader loss due to ZK session expiry
[ https://issues.apache.org/jira/browse/SOLR-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe reassigned SOLR-5593: Assignee: Mark Miller (was: Steve Rowe) I didn't mean to reassign - I was typing in another window, accidentally hit the mouse button with my elbow, which focused the browser window with this issue up, and then I guess JIRA interpreted my random typing as keyboard shortcuts shard leader loss due to ZK session expiry -- Key: SOLR-5593 URL: https://issues.apache.org/jira/browse/SOLR-5593 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Christine Poerschke Assignee: Mark Miller Fix For: 5.0, 4.7, 4.6.1 Attachments: CoreAdminHandler.patch The problem we saw was that the shard leader ceased to be shard leader (in our case due to its zookeeper session expiring). The followers thus rejected update requests (DistributedUpdateProcessor setupRequest's call to ZkStateReader getLeaderRetry) and the leader asked them to recover (DistributedUpdateProcessor doFinish). The followers published themselves as recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard leader loss triggered an election in which none of the followers became the leader due to their recovering state (ShardLeaderElectionContext shouldIBeLeader). The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). -- 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-4x-Linux-Java6-64-test-only - Build # 8667 - Still Failing!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java6-64-test-only/8667/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[jira] [Updated] (SOLR-5474) Have a new mode for SolrJ to not watch any ZKNode
[ https://issues.apache.org/jira/browse/SOLR-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter updated SOLR-5474: - Attachment: (was: SOLR-5474.patch) Have a new mode for SolrJ to not watch any ZKNode - Key: SOLR-5474 URL: https://issues.apache.org/jira/browse/SOLR-5474 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul In this mode SolrJ would not watch any ZK node It fetches the state on demand and cache the most recently used n collections in memory. SolrJ would not listen to any ZK node. When a request comes for a collection ‘xcoll’ it would first check if such a collection exists If yes it first looks up the details in the local cache for that collection If not found in cache , it fetches the node /collections/xcoll/state.json and caches the information Any query/update will be sent with extra query param specifying the collection name , shard name, Role (Leader/Replica), and range (example \_target_=xcoll:shard1:L:8000-b332) . A node would throw an error (INVALID_NODE) if it does not the serve the collection/shard/Role/range combo. If SolrJ gets INVALID_NODE error it would invalidate the cache and fetch fresh state information for that collection (and caches it again) If there is a connection timeout, SolrJ assumes the node is down and re-fetch the state for the collection and try again -- 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-trunk-Linux-Java7-64-test-only - Build # 72346 - Still Failing!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/72346/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[jira] [Updated] (SOLR-5474) Have a new mode for SolrJ to not watch any ZKNode
[ https://issues.apache.org/jira/browse/SOLR-5474?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Timothy Potter updated SOLR-5474: - Attachment: SOLR-5474.patch Previous patch file was created incorrectly with git ... Have a new mode for SolrJ to not watch any ZKNode - Key: SOLR-5474 URL: https://issues.apache.org/jira/browse/SOLR-5474 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Attachments: SOLR-5474.patch In this mode SolrJ would not watch any ZK node It fetches the state on demand and cache the most recently used n collections in memory. SolrJ would not listen to any ZK node. When a request comes for a collection ‘xcoll’ it would first check if such a collection exists If yes it first looks up the details in the local cache for that collection If not found in cache , it fetches the node /collections/xcoll/state.json and caches the information Any query/update will be sent with extra query param specifying the collection name , shard name, Role (Leader/Replica), and range (example \_target_=xcoll:shard1:L:8000-b332) . A node would throw an error (INVALID_NODE) if it does not the serve the collection/shard/Role/range combo. If SolrJ gets INVALID_NODE error it would invalidate the cache and fetch fresh state information for that collection (and caches it again) If there is a connection timeout, SolrJ assumes the node is down and re-fetch the state for the collection and try again -- 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-4x-Linux-Java6-64-test-only - Build # 8668 - Still Failing!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java6-64-test-only/8668/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 72347 - Still Failing!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/72347/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[JENKINS] Solr-Artifacts-trunk - Build # 2395 - Failure
Build: https://builds.apache.org/job/Solr-Artifacts-trunk/2395/ No tests ran. Build Log: [...truncated 238 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:908) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:889) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:872) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2461) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 36 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 35 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 36 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-4x-Linux-Java6-64-test-only - Build # 8669 - Still Failing!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java6-64-test-only/8669/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 72348 - Still Failing!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/72348/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[JENKINS] Lucene-4x-Linux-Java6-64-test-only - Build # 8670 - Still Failing!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java6-64-test-only/8670/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 72349 - Still Failing!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/72349/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[jira] [Updated] (SOLR-5463) Provide cursor/token based searchAfter support that works with arbitrary sorting (ie: deep paging)
[
https://issues.apache.org/jira/browse/SOLR-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-5463:
-
Attachment: SOLR-5463.patch
Patch with a few changes added onto Hoss's most recent patch.
{quote}
bq. I accidentally discovered that a blank cursorMark request param is ignored
- is this intentional? I ask because although
CursorMark.parseSerializedTotem() throws an exception about the bad format of
an empty totem, QueryComponent.prepare() ignores a blank cursorMark param:
Yeah .. that was intentional. My thinking was that from CursorMark's
perspective, attempting to parse a null or blank string was not valid – but
from QueryComponent's perspective, a null or blank string ment do not
construct a CursorMark object at all
the basic motivation being that it didn't seem like it should be an error to
have something like /select?q=foocursorMark=... ... but i'm not adamant that
it should work that way.
In fact, thinking about it more, and looking at how some other params (like
start, rows, facet, etc...) deal with blank strings, i agree with you – it
should be an error.
{quote}
I changed the behavior to make blank {{cursorMark}} params raise an error, and
added a couple tests for it to {{CursorMarkTest}}.
I fixed a few misspellings in comments, and removed a few unused imports.
I added a new test {{TestCursorMarkWithoutUniqueKey}}.
I substituted {{CURSOR_MARK_PARAM}} for {{cursorMark}}, and
{{CURSOR_MARK_START}} for {{\*}} in {{CursorPagingTest}}.
Provide cursor/token based searchAfter support that works with arbitrary
sorting (ie: deep paging)
--
Key: SOLR-5463
URL: https://issues.apache.org/jira/browse/SOLR-5463
Project: Solr
Issue Type: New Feature
Reporter: Hoss Man
Assignee: Hoss Man
Attachments: SOLR-5463.patch, SOLR-5463.patch, SOLR-5463.patch,
SOLR-5463.patch, SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch,
SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch,
SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch,
SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch,
SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch,
SOLR-5463__straw_man__MissingStringLastComparatorSource.patch
I'd like to revist a solution to the problem of deep paging in Solr,
leveraging an HTTP based API similar to how IndexSearcher.searchAfter works
at the lucene level: require the clients to provide back a token indicating
the sort values of the last document seen on the previous page. This is
similar to the cursor model I've seen in several other REST APIs that
support pagnation over a large sets of results (notable the twitter API and
it's since_id param) except that we'll want something that works with
arbitrary multi-level sort critera that can be either ascending or descending.
SOLR-1726 laid some initial ground work here and was commited quite a while
ago, but the key bit of argument parsing to leverage it was commented out due
to some problems (see comments in that issue). It's also somewhat out of
date at this point: at the time it was commited, IndexSearcher only supported
searchAfter for simple scores, not arbitrary field sorts; and the params
added in SOLR-1726 suffer from this limitation as well.
---
I think it would make sense to start fresh with a new issue with a focus on
ensuring that we have deep paging which:
* supports arbitrary field sorts in addition to sorting by score
* works in distributed mode
--
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-Tests-4.x-Java6 - Build # 2247 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/2247/ No tests ran. Build Log: [...truncated 115 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:908) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:889) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:872) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2461) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 36 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 35 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 36 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-4x-Linux-Java6-64-test-only - Build # 8671 - Still Failing!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java6-64-test-only/8671/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 72350 - Still Failing!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/72350/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[JENKINS] Lucene-4x-Linux-Java6-64-test-only - Build # 8672 - Still Failing!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java6-64-test-only/8672/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 72351 - Still Failing!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/72351/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[JENKINS] Lucene-Solr-Tests-4.x-Java7 - Build # 1840 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java7/1840/ No tests ran. Build Log: [...truncated 6 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:908) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:889) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:872) at hudson.FilePath$FileCallableWrapper.call(FilePath.java:2461) at hudson.remoting.UserRequest.perform(UserRequest.java:118) at hudson.remoting.UserRequest.perform(UserRequest.java:48) at hudson.remoting.Request$2.run(Request.java:328) at hudson.remoting.InterceptingExecutorService$1.call(InterceptingExecutorService.java:72) at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) at java.util.concurrent.FutureTask.run(FutureTask.java:166) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1146) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) at java.lang.Thread.run(Thread.java:679) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 36 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 35 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 36 more Caused by: svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at
[JENKINS] Lucene-4x-Linux-Java6-64-test-only - Build # 8673 - Still Failing!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java6-64-test-only/8673/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 72352 - Still Failing!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/72352/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[JENKINS] Lucene-4x-Linux-Java6-64-test-only - Build # 8674 - Still Failing!
Build: builds.flonkings.com/job/Lucene-4x-Linux-Java6-64-test-only/8674/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[jira] [Commented] (SOLR-5593) shard leader loss due to ZK session expiry
[ https://issues.apache.org/jira/browse/SOLR-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859683#comment-13859683 ] Mark Miller commented on SOLR-5593: --- bq. Yes, we are working on changes to DistributedUpdateProcessor to relax the requirement for the getLeaderRetry to succeed within setupRequest (if phase is DistribPhase.FROMLEADER and the shard state shows it could not be subShardLeader then getLeaderRetry success should be optional). Yeah, on some thought, this is the right approach I think. Removing the publish is actually probably not a good idea. It actually protects us from losing data - we don't want a replica that was asked to recover to become the leader - that could mean updates were accepted that it is expected to have. If the previous leader died before one of the replicas became a leader, that leader might have been ahead. In this case, we don't choose a new leader, because you should really reboot the whole shard with all the replicas you can to avoid any possible data lose. shard leader loss due to ZK session expiry -- Key: SOLR-5593 URL: https://issues.apache.org/jira/browse/SOLR-5593 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Christine Poerschke Assignee: Mark Miller Fix For: 5.0, 4.7, 4.6.1 Attachments: CoreAdminHandler.patch The problem we saw was that the shard leader ceased to be shard leader (in our case due to its zookeeper session expiring). The followers thus rejected update requests (DistributedUpdateProcessor setupRequest's call to ZkStateReader getLeaderRetry) and the leader asked them to recover (DistributedUpdateProcessor doFinish). The followers published themselves as recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard leader loss triggered an election in which none of the followers became the leader due to their recovering state (ShardLeaderElectionContext shouldIBeLeader). The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). -- 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-trunk-Linux-Java7-64-test-only - Build # 72353 - Still Failing!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/72353/ No tests ran. Build Log: [...truncated 5 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/trunk org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:388) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:373) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:361) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.performHttpRequest(DAVConnection.java:707) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:627) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:102) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1020) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:148) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:339) at org.tmatesoft.svn.core.internal.wc16.SVNBasicDelegate.createRepository(SVNBasicDelegate.java:328) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.update(SVNUpdateClient16.java:482) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:364) at org.tmatesoft.svn.core.internal.wc16.SVNUpdateClient16.doUpdate(SVNUpdateClient16.java:274) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:27) at org.tmatesoft.svn.core.internal.wc2.old.SvnOldUpdate.run(SvnOldUpdate.java:11) at org.tmatesoft.svn.core.internal.wc2.SvnOperationRunner.run(SvnOperationRunner.java:20) at org.tmatesoft.svn.core.wc2.SvnOperationFactory.run(SvnOperationFactory.java:1238) at org.tmatesoft.svn.core.wc2.SvnOperation.run(SvnOperation.java:294) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:311) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:291) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:387) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:157) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:161) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:910) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:891) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:874) at hudson.FilePath.act(FilePath.java:914) at hudson.FilePath.act(FilePath.java:887) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:850) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:788) at hudson.model.AbstractProject.checkout(AbstractProject.java:1414) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:652) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:561) at hudson.model.Run.execute(Run.java:1678) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:231) Caused by: svn: E175002: OPTIONS /repos/asf/lucene/dev/trunk failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:154) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:97) ... 38 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' svn: E175002: timed out waiting for server at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:777) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:382) ... 37 more Caused by: svn: E175002: OPTIONS request failed on '/repos/asf/lucene/dev/trunk' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:208) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:775) ... 38 more Caused by: svn: E175002: timed out waiting for server at
[jira] [Commented] (SOLR-5593) shard leader loss due to ZK session expiry
[ https://issues.apache.org/jira/browse/SOLR-5593?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859684#comment-13859684 ] Mark Miller commented on SOLR-5593: --- bq within setupRequest The tough case seems to be nailing delete by query - I've been peaking a bit at it. shard leader loss due to ZK session expiry -- Key: SOLR-5593 URL: https://issues.apache.org/jira/browse/SOLR-5593 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Christine Poerschke Assignee: Mark Miller Fix For: 5.0, 4.7, 4.6.1 Attachments: CoreAdminHandler.patch The problem we saw was that the shard leader ceased to be shard leader (in our case due to its zookeeper session expiring). The followers thus rejected update requests (DistributedUpdateProcessor setupRequest's call to ZkStateReader getLeaderRetry) and the leader asked them to recover (DistributedUpdateProcessor doFinish). The followers published themselves as recovering (CoreAdminHandler handleRequestRecoveryAction) and the shard leader loss triggered an election in which none of the followers became the leader due to their recovering state (ShardLeaderElectionContext shouldIBeLeader). The former shard leader also did not become shard leader because its new seq number placed it after the existing replicas (LeaderElector checkIfIamLeader seq = intSeqs.get(0)). -- 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-5507) Admin UI - Refactoring using AngularJS
[ https://issues.apache.org/jira/browse/SOLR-5507?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859692#comment-13859692 ] Kranti Parisa commented on SOLR-5507: - This is cool. I was thinking on the same stuff. It would be awesome to add a section on the Admin UI to display the CUSTOM INSTANCE INFO. For example Instance: INDEXER Version/Release Number: 1.0.1 and more.. These values could be read from solrconfig.xml or so. Solr could be installed as INDEXER (Master) and QUERYENGINE (Slave) on different data centers with different versions in a typical production environment. It would be nice to have a facility to write some custom info into solrconfig.xml or so during the installation and that can be displayed right on the Solr Admin UI. Admin UI - Refactoring using AngularJS -- Key: SOLR-5507 URL: https://issues.apache.org/jira/browse/SOLR-5507 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor On the LSR in Dublin, i've talked again to [~upayavira] and this time we talked about Refactoring the existing UI - using AngularJS: providing (more, internal) structure and what not ; He already started working on the Refactoring, so this is more a 'tracking' issue about the progress he/we do there. Will extend this issue with a bit more context additional information, w/ thoughts about the possible integration in the existing UI and more (: -- 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: Adding preserveOriginal Capability to EdgeNGramFilterFactory
Sorry for the late reply. But here is what I was talking about big bang = b bi big (skipping the words other than the first one) big bang = b ba ban bang (skipping the first word) big bang = a an ang (skipping the first word + skipping first letter in subsequent words) The reason for this is to apply custom boosting for the matches based on where the search term matches (start, middle, end etc). May be we should use RegEx before EdgeNGramFilterFactory? But I was thinking to have EdgeNGramFilterFactory take a parameter to skip n characters from the start or end before generating the grams. Your thoughts? Thanks, Kranti K. Parisa http://www.linkedin.com/in/krantiparisa On Wed, Nov 13, 2013 at 6:38 AM, Furkan KAMACI furkankam...@gmail.comwrote: EdgeNGramFilterFactory creates n-grams from the beginning edge of a input token by default. You can change its side. You can define minimum and maximum gram size for it. Here is what *can *EdgeNGramFilterFactory do with a configuration of minimum gram size is 2 and maximum gram size is 4: apache = ap, apa, apac, apach If we talk about your situation. What is a word for you? Strings that are delimited by whitespaces, underscores ... etc? 2013/11/12 Kranti Parisa kranti.par...@gmail.com Can EdgeNGramFilterFactory handle the cases where we need to skip/consider the n words from the start or end? For example: Title: big bang theory field1: populate full ngrams field2: populate ngrams for bang theory = skipping the first word big field3: populate ngrams for big = considering only the first word big field4: populate ngrams for theory = considering only the last word theory and at query time, I would like to apply field level boosting to rank the results. Thanks, Kranti K. Parisa http://www.linkedin.com/in/krantiparisa On Sun, Nov 10, 2013 at 5:51 PM, Furkan KAMACI furkankam...@gmail.comwrote: Hi; There were two issues about adding preserveOriginal capability to EdgeNGramFilterFactory and I've made a patch about it. You can check and test it from here: https://issues.apache.org/jira/browse/SOLR-5152 This is the related issue that can be marked as duplicated: https://issues.apache.org/jira/browse/SOLR-5332 Thanks; Furkan KAMACI
[jira] [Updated] (SOLR-5580) SOLR-5311 was done without full understanding of the system and must be reverted.
[
https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-5580:
--
Summary: SOLR-5311 was done without full understanding of the system and
must be reverted. (was: NPE when create a core with both explicite shard and
coreNodeName)
SOLR-5311 was done without full understanding of the system and must be
reverted.
-
Key: SOLR-5580
URL: https://issues.apache.org/jira/browse/SOLR-5580
Project: Solr
Issue Type: Bug
Affects Versions: 4.6
Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
Software:solr 4.6,
jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
Reporter: YouPeng Yang
Assignee: Mark Miller
Labels: core
Fix For: 5.0, 4.7, 4.6.1
Original Estimate: 0.5h
Remaining Estimate: 0.5h
In class org.apache.solr.cloud.Overseer the Line 360:
-
if (sliceName !=null collectionExists
!true.equals(state.getCollection(collection).getStr(autoCreated))) {
Slice slice = state.getSlice(collection, sliceName);
if (slice.getReplica(coreNodeName) == null) {
log.info(core_deleted . Just return);
return state;
}
}
-
the slice needs to be checked null .because when create a new core with both
explicite shard and coreNodeName, the state.getSlice(collection, sliceName)
may return a null.So it needs to be checked ,or there will be an
NullpointException
-
if (sliceName !=null collectionExists
!true.equals(state.getCollection(collection).getStr(autoCreated))) {
Slice slice = state.getSlice(collection, sliceName);
if (slice != null slice.getReplica(coreNodeName) == null) {
log.info(core_deleted . Just return);
return state;
}
}
-
--
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-5580) NPE when create a core with both explicite shard and coreNodeName
[
https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859703#comment-13859703
]
Mark Miller commented on SOLR-5580:
---
No dude, the description of this issue is just not correct.
You broke SolrCloud and I won't allow that code back in. -1, it's broken. In
4.6.1 we need to remove it.
NPE when create a core with both explicite shard and coreNodeName
--
Key: SOLR-5580
URL: https://issues.apache.org/jira/browse/SOLR-5580
Project: Solr
Issue Type: Bug
Affects Versions: 4.6
Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
Software:solr 4.6,
jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
Reporter: YouPeng Yang
Assignee: Mark Miller
Labels: core
Fix For: 5.0, 4.7, 4.6.1
Original Estimate: 0.5h
Remaining Estimate: 0.5h
In class org.apache.solr.cloud.Overseer the Line 360:
-
if (sliceName !=null collectionExists
!true.equals(state.getCollection(collection).getStr(autoCreated))) {
Slice slice = state.getSlice(collection, sliceName);
if (slice.getReplica(coreNodeName) == null) {
log.info(core_deleted . Just return);
return state;
}
}
-
the slice needs to be checked null .because when create a new core with both
explicite shard and coreNodeName, the state.getSlice(collection, sliceName)
may return a null.So it needs to be checked ,or there will be an
NullpointException
-
if (sliceName !=null collectionExists
!true.equals(state.getCollection(collection).getStr(autoCreated))) {
Slice slice = state.getSlice(collection, sliceName);
if (slice != null slice.getReplica(coreNodeName) == null) {
log.info(core_deleted . Just return);
return state;
}
}
-
--
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-5311) Avoid registering replicas which are removed
[ https://issues.apache.org/jira/browse/SOLR-5311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859705#comment-13859705 ] Mark Miller commented on SOLR-5311: --- This cannot be part of SolrCloud as is. It was rushed in without fully understanding the system and with terrible tests (I had to spend a lot of time working on them to fix them). This implementation breaks the proper functioning of SolrCloud. I've explained how it can be properly implemented above. There may be other options as well. The naive option here creates many bugs and must be removed for 4.6.1. Avoid registering replicas which are removed - Key: SOLR-5311 URL: https://issues.apache.org/jira/browse/SOLR-5311 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Noble Paul Assignee: Noble Paul Fix For: 4.6, 5.0 Attachments: SOLR-5311.patch, SOLR-5311.patch, SOLR-5311.patch, SOLR-5311.patch, SOLR-5311.patch, SOLR-5311.patch, SOLR-5311.patch If a replica is removed from the clusterstate and if it comes back up it should not be allowed to register. Each core ,when comes up, checks if it was already registered and if yes is it still there. If not ,throw an error and do an unregister . If such a request come to overseer it should ignore such a core -- 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-3197) Allow firstSearcher and newSearcher listeners to run in multiple threads
[
https://issues.apache.org/jira/browse/SOLR-3197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859720#comment-13859720
]
Kranti Parisa commented on SOLR-3197:
-
I like the idea of having a configurable option, say
warmupThreads1/warmupThreads
so that user can change the number based on their needs.
Neil, to your point When Solr is configured not to serve queries while
warming how can we do this when the instance is in a cluster under load
balancer?
Allow firstSearcher and newSearcher listeners to run in multiple threads
Key: SOLR-3197
URL: https://issues.apache.org/jira/browse/SOLR-3197
Project: Solr
Issue Type: Improvement
Reporter: Lance Norskog
SolrCore submits all listeners (firstSearcher and newSearcher) to a java
ExecutorService, but uses a single-threaded one.
line 965 in the trunk:
{code}
SolrCore.java around line 965: final ExecutorService searcherExecutor =
Executors.newSingleThreadExecutor();
line 1280 in the trunk:
SolrCore.java around line 1280 runs first the, and then the first and new
searchers, all with the searcherExecutor object created at line 965.
Would it work if we changed this ExecutorService to a thread pool version?
This seems like it should work:
{code}
java.util.concurrent.Executors.newFixedThreadPool(int nThreads, ThreadFactory
threadFactory);
{code}
--
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-5580) SOLR-5311 was done without full understanding of the system and must be reverted.
[
https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859727#comment-13859727
]
Mark Miller commented on SOLR-5580:
---
The NPE was just a surface bug that a user hit.
The actual bug here is:
* You cannot count on coreNodeName like SOLR-5311 - totally illegal.
* You cannot use this autoCreated property. Totally illegal in the current
system.
* Cores can stick around, and simply don't get updates into the cluster state?
A lot of ugliness around this...and...
* In general, this is a hack, half hearted attempt at making ZooKeeper the
truth.
All these issues lead to many bugs.
There are non buggy, full solutions to making ZooKeeper the truth, and if that
is what you are after, we have to do it in a way that is consistent with the
current system.
SOLR-5311 was done without full understanding of the system and must be
reverted.
-
Key: SOLR-5580
URL: https://issues.apache.org/jira/browse/SOLR-5580
Project: Solr
Issue Type: Bug
Affects Versions: 4.6
Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
Software:solr 4.6,
jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
Reporter: YouPeng Yang
Assignee: Mark Miller
Labels: core
Fix For: 5.0, 4.7, 4.6.1
Original Estimate: 0.5h
Remaining Estimate: 0.5h
In class org.apache.solr.cloud.Overseer the Line 360:
-
if (sliceName !=null collectionExists
!true.equals(state.getCollection(collection).getStr(autoCreated))) {
Slice slice = state.getSlice(collection, sliceName);
if (slice.getReplica(coreNodeName) == null) {
log.info(core_deleted . Just return);
return state;
}
}
-
the slice needs to be checked null .because when create a new core with both
explicite shard and coreNodeName, the state.getSlice(collection, sliceName)
may return a null.So it needs to be checked ,or there will be an
NullpointException
-
if (sliceName !=null collectionExists
!true.equals(state.getCollection(collection).getStr(autoCreated))) {
Slice slice = state.getSlice(collection, sliceName);
if (slice != null slice.getReplica(coreNodeName) == null) {
log.info(core_deleted . Just return);
return state;
}
}
-
--
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-5463) Provide cursor/token based searchAfter support that works with arbitrary sorting (ie: deep paging)
[ https://issues.apache.org/jira/browse/SOLR-5463?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-5463: --- Attachment: SOLR-5463.patch More patch improvements.. * cleaned up the test nocommits related to the startAt value (for now it's just 0, sarowe opened LUCENE-5380 with his other idea, we can revist and change the cursor code/test later if/when that goes through) * added some comments regarding potential improvements via SOLR-5595 * cleaned up some nocommits that were acting as reminders of things i wanted to review later with fresh eyes * converted some nocommit asserts to clean user exceptions * user exception if attempting to combine cursor with timeAllowed (sarowe pointed this out to me in IRC: the nextCursorMark would make no sense) * added more tests for bad user input conditions Provide cursor/token based searchAfter support that works with arbitrary sorting (ie: deep paging) -- Key: SOLR-5463 URL: https://issues.apache.org/jira/browse/SOLR-5463 Project: Solr Issue Type: New Feature Reporter: Hoss Man Assignee: Hoss Man Attachments: SOLR-5463.patch, SOLR-5463.patch, SOLR-5463.patch, SOLR-5463.patch, SOLR-5463.patch, SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, SOLR-5463__straw_man.patch, SOLR-5463__straw_man__MissingStringLastComparatorSource.patch I'd like to revist a solution to the problem of deep paging in Solr, leveraging an HTTP based API similar to how IndexSearcher.searchAfter works at the lucene level: require the clients to provide back a token indicating the sort values of the last document seen on the previous page. This is similar to the cursor model I've seen in several other REST APIs that support pagnation over a large sets of results (notable the twitter API and it's since_id param) except that we'll want something that works with arbitrary multi-level sort critera that can be either ascending or descending. SOLR-1726 laid some initial ground work here and was commited quite a while ago, but the key bit of argument parsing to leverage it was commented out due to some problems (see comments in that issue). It's also somewhat out of date at this point: at the time it was commited, IndexSearcher only supported searchAfter for simple scores, not arbitrary field sorts; and the params added in SOLR-1726 suffer from this limitation as well. --- I think it would make sense to start fresh with a new issue with a focus on ensuring that we have deep paging which: * supports arbitrary field sorts in addition to sorting by score * works in distributed mode -- 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-5580) SOLR-5311 was done without full understanding of the system and must be reverted.
[
https://issues.apache.org/jira/browse/SOLR-5580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13859828#comment-13859828
]
Noble Paul commented on SOLR-5580:
--
I think, the core of the issue is whether to have an option of removing a core
from the cluster without touching to the node itself?
If that option can be provided can it be implemented without introducing
backward compatibility issues?
I believe , in a reasonably big cluster, nobody would want to deal with
individual nodes to manage the cluster . So , they would like to go through the
API to achieve almost everything. Do we wish to introduce a new mode for these
things? Or do we want it to be the default mode?
If we can implement the new mode without breaking existing features , do we
need to introduce a new mode? the reason I'm asking these questions is because
users tend to use the default mode assuming that is the best. a new mode is
always a problem because that is kind of forking the system. That will be a
support nightmare
Before getting into Implementation details , we need to build consensus on
these things first .
SOLR-5311 was done without full understanding of the system and must be
reverted.
-
Key: SOLR-5580
URL: https://issues.apache.org/jira/browse/SOLR-5580
Project: Solr
Issue Type: Bug
Affects Versions: 4.6
Environment: OS:Red Hat Enterprise Linux Server release 6.4 (Santiago)
Software:solr 4.6,
jdk:OpenJDK Runtime Environment (rhel-2.3.4.1.el6_3-x86_64)
OpenJDK 64-Bit Server VM (build 23.2-b09, mixed mode)
Reporter: YouPeng Yang
Assignee: Mark Miller
Labels: core
Fix For: 5.0, 4.7, 4.6.1
Original Estimate: 0.5h
Remaining Estimate: 0.5h
In class org.apache.solr.cloud.Overseer the Line 360:
-
if (sliceName !=null collectionExists
!true.equals(state.getCollection(collection).getStr(autoCreated))) {
Slice slice = state.getSlice(collection, sliceName);
if (slice.getReplica(coreNodeName) == null) {
log.info(core_deleted . Just return);
return state;
}
}
-
the slice needs to be checked null .because when create a new core with both
explicite shard and coreNodeName, the state.getSlice(collection, sliceName)
may return a null.So it needs to be checked ,or there will be an
NullpointException
-
if (sliceName !=null collectionExists
!true.equals(state.getCollection(collection).getStr(autoCreated))) {
Slice slice = state.getSlice(collection, sliceName);
if (slice != null slice.getReplica(coreNodeName) == null) {
log.info(core_deleted . Just return);
return state;
}
}
-
--
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 # 1150 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/1150/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 10466 lines...] [junit4] JVM J0: stdout was not empty, see: /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/temp/junit4-J0-20140101_061005_984.sysout [junit4] JVM J0: stdout (verbatim) [junit4] # [junit4] # A fatal error has been detected by the Java Runtime Environment: [junit4] # [junit4] # SIGSEGV (0xb) at pc=0x000107a71a2b, pid=565, tid=70443 [junit4] # [junit4] # JRE version: Java(TM) SE Runtime Environment (7.0_45-b18) (build 1.7.0_45-b18) [junit4] # Java VM: Java HotSpot(TM) 64-Bit Server VM (24.45-b08 mixed mode bsd-amd64 ) [junit4] # Problematic frame: [junit4] # C [libjava.dylib+0x9a2b] JNU_NewStringPlatform+0x1d3 [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] # /Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/J0/hs_err_pid565.log [junit4] # [junit4] # If you would like to submit a bug report, please visit: [junit4] # http://bugreport.sun.com/bugreport/crash.jsp [junit4] # The crash happened outside the Java Virtual Machine in native code. [junit4] # See problematic frame for where to report the bug. [junit4] # [junit4] JVM J0: EOF [...truncated 1 lines...] [junit4] ERROR: JVM J0 ended with an exception, command line: /Library/Java/JavaVirtualMachines/jdk1.7.0_45.jdk/Contents/Home/jre/bin/java -XX:-UseCompressedOops -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/heapdumps -Dtests.prefix=tests -Dtests.seed=C05E0C3445D58192 -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=4.7 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/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=. -Djunit4.tempDir=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/temp -Dclover.db.dir=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/Users/jenkins/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/tests.policy -Dlucene.version=4.7-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=US-ASCII -classpath
