Solr nightly build failure
init-forrest-entities: [mkdir] Created dir: /tmp/apache-solr-nightly/build [mkdir] Created dir: /tmp/apache-solr-nightly/build/web compile-solrj: [mkdir] Created dir: /tmp/apache-solr-nightly/build/solrj [javac] Compiling 73 source files to /tmp/apache-solr-nightly/build/solrj [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile: [mkdir] Created dir: /tmp/apache-solr-nightly/build/solr [javac] Compiling 351 source files to /tmp/apache-solr-nightly/build/solr [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compileTests: [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests [javac] Compiling 139 source files to /tmp/apache-solr-nightly/build/tests [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. junit: [mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results [junit] Running org.apache.solr.BasicFunctionalityTest [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 20.661 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.169 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 6.078 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 3.272 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 3.043 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.927 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.939 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 37.403 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 0.471 sec [junit] Running org.apache.solr.analysis.DoubleMetaphoneFilterTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.445 sec [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.816 sec [junit] Running org.apache.solr.analysis.HTMLStripReaderTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.977 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.731 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.724 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.287 sec [junit] Running org.apache.solr.analysis.TestCharFilter [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.424 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.655 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.289 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilter [junit] Tests run: 11, Failures: 0, Errors: 0, Time elapsed: 0.478 sec [junit] Running org.apache.solr.analysis.TestMappingCharFilterFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.59 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures: 0, Errors: 0, Time elapsed: 1.803 sec [junit] Running org.apache.solr.analysis.TestPatternTokenizerFactory [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.007 sec [junit] Running org.apache.solr.analysis.TestPhoneticFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.207 sec [junit] Running org.apache.solr.analysis.TestRemoveDuplicatesTokenFilter [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 2.074 sec [junit] Running org.apache.solr.analysis.TestSynonymFilter [junit] Tests run: 7, Failures: 0, Errors: 0, Time elapsed: 3.464 sec [junit] Running org.apache.solr.analysis.TestSy
Build failed in Hudson: Solr-trunk #698
See http://hudson.zones.apache.org/hudson/job/Solr-trunk/698/changes Changes: [yonik] Upgraded to Lucene 2.9-dev r738345 [shalin] SOLR-980 -- A PlainTextEntityProcessor which can read from any DataSource and output a String -- [...truncated 2056 lines...] [junit] Tests run: 8, Failures: 0, Errors: 0, Time elapsed: 14.639 sec [junit] Running org.apache.solr.handler.component.TermVectorComponentTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 7.649 sec [junit] Running org.apache.solr.handler.component.TermsComponentTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 17.431 sec [junit] Running org.apache.solr.highlight.HighlighterConfigTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.854 sec [junit] Running org.apache.solr.highlight.HighlighterTest [junit] Tests run: 20, Failures: 0, Errors: 0, Time elapsed: 21.756 sec [junit] Running org.apache.solr.request.JSONWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 4.685 sec [junit] Running org.apache.solr.request.SimpleFacetsLegacySortTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.087 sec [junit] Running org.apache.solr.request.SimpleFacetsTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 10.034 sec [junit] Running org.apache.solr.request.TestBinaryResponseWriter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.89 sec [junit] Running org.apache.solr.request.TestFaceting [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 14.238 sec [junit] Running org.apache.solr.request.TestWriterPerf [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.75 sec [junit] Running org.apache.solr.schema.BadIndexSchemaTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.838 sec [junit] Running org.apache.solr.schema.CopyFieldTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 7.215 sec [junit] Running org.apache.solr.schema.DateFieldTest [junit] Tests run: 6, Failures: 0, Errors: 0, Time elapsed: 0.422 sec [junit] Running org.apache.solr.schema.IndexSchemaTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 4.992 sec [junit] Running org.apache.solr.schema.LegacyDateFieldTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 0.427 sec [junit] Running org.apache.solr.schema.NotRequiredUniqueKeyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 1.856 sec [junit] Running org.apache.solr.schema.RequiredFieldsTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 4.827 sec [junit] Running org.apache.solr.schema.UUIDFieldTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.675 sec [junit] Running org.apache.solr.search.TestDocSet [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.894 sec [junit] Running org.apache.solr.search.TestFastLRUCache [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.403 sec [junit] Running org.apache.solr.search.TestQueryTypes [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 2.791 sec [junit] Running org.apache.solr.search.TestQueryUtils [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 3.254 sec [junit] Running org.apache.solr.search.function.TestFunctionQuery [junit] [junit] [junit] [junit] 0 [junit] 2 [junit] [junit] [junit] [junit] 543210.0 [junit] 54321.0 [junit] [junit] [junit] 250.0 [junit] 25.0 [junit] [junit] [junit] 1.0 [junit] 100.0 [junit] [junit] [junit] 1.0 [junit] -4.0 [junit] [junit] [junit] 1.0 [junit] 10.0 [junit] [junit] [junit] 1.0 [junit] 5.0 [junit] [junit] [junit] 1.0 [junit] 77.0 [junit] [junit] [junit] 1.0 [junit] 23.0 [junit] [junit] [junit] 1.0 [junit] 55.0 [junit] [junit] [junit] 1.0 [junit] -78.0 [junit] [junit] [junit] 1.0 [junit] -45.0 [junit] [junit] [junit] 1.0 [junit] -24.0 [junit] [junit] [junit] 1.0 [junit] 63.0 [junit] [junit] [junit] 1.0 [junit] 78.0 [junit] [junit] [junit] 1.0 [junit] 94.0 [junit] [junit] [junit] 1.0 [junit] 22.0 [junit] [junit] [junit] 1.0 [junit] 34.0 [junit] [junit] [junit] 1.0 [junit] 261.0 [junit] [junit] [junit] 1.0 [junit] -627.0 [junit] [junit] [junit] 1.0 [junit] 1.0 [junit] [junit] [junit] 1.0 [junit] 10001.0 [junit] [junit] [junit] -999.0 [junit] 0.0 [junit]
Registration for ApacheCon Europe 2009 is now open!
Cross-posting this announcement. There are several relevant Lucene/ Solr talks including: Trainings - Lucene Boot Camp (Grant Ingersoll) - Solr Boot Camp (Erik Hatcher) Sessions - Introducing Apache Mahout (Grant) - Lucene Case Studies (Erik) - Advanced Indexing Techniques with Apache Lucene (Michael Busch) And a whole slew of Hadoop/cloud coverage. Erik -- ApacheCon EU 2009 registration is now open! 23-27 March -- Mövenpick Hotel, Amsterdam, Netherlands http://www.eu.apachecon.com/ Registration for ApacheCon Europe 2009 is now open - act before early bird prices expire 6 February. Remember to book a room at the Mövenpick and use the Registration Code: Special package attendees for the conference registration, and get 150 Euros off your full conference registration. Lower Costs - Thanks to new VAT tax laws, our prices this year are 19% lower than last year in Europe! We've also negotiated a Mövenpick rate of a maximum of 155 Euros per night for attendees in our room block. Quick Links: http://xrl.us/aceu09sp See the schedule http://xrl.us/aceu09hp Get your hotel room http://xrl.us/aceu09rp Register for the conference Other important notes: - Geeks for Geeks is a new mini-track where we can feature advanced technical content from project committers. And our Hackathon on Monday and Tuesday is open to all attendees - be sure to check it off in your registration. - The Call for Papers for ApacheCon US 2009, held 2-6 November 2009 in Oakland, CA, is open through 28 February, so get your submissions in now. This ApacheCon will feature special events with some of the ASF's original founders in celebration of the 10th anniversary of The Apache Software Foundation. http://www.us.apachecon.com/c/acus2009/ - Interested in sponsoring the ApacheCon conferences? There are plenty of sponsor packages available - please contact Delia Frees at de...@apachecon.com for further information. == ApacheCon EU 2008: A week of Open Source at it's best! Hackathon - open to all! | Geeks for Geeks | Lunchtime Sessions In-Depth Trainings | Multi-Track Sessions | BOFs | Business Panel Lightning Talks | Receptions | Fast Feather Track | Expo... and more! - Shane Curcuru, on behalf of Noirin Shirley, Conference Lead, and the whole ApacheCon Europe 2009 Team http://www.eu.apachecon.com/ 23-27 March -- Amsterdam, Netherlands
[jira] Commented: (SOLR-341) PHP Solr Client
[ https://issues.apache.org/jira/browse/SOLR-341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668470#action_12668470 ] Mark Lindeman commented on SOLR-341: in Apache/Solr/Document.php on line 218: $this->_fieldBoosts = $boost; this should be: $this->_fieldBoosts[$key] = $boost; If I do not use the $fieldboost parameter in setField() method, than I end up with a document full off boost="" parameters which triggers errors in Solr 1.3 > PHP Solr Client > --- > > Key: SOLR-341 > URL: https://issues.apache.org/jira/browse/SOLR-341 > Project: Solr > Issue Type: New Feature > Components: clients - php >Affects Versions: 1.2 > Environment: PHP >= 5.2.0 (or older with JSON PECL extension or other > json_decode function implementation). Solr >= 1.2 >Reporter: Donovan Jimenez >Priority: Trivial > Fix For: 1.4 > > Attachments: SolrPhpClient.2008-09-02.zip, > SolrPhpClient.2008-11-14.zip, SolrPhpClient.2008-11-25.zip, SolrPhpClient.zip > > > Developed this client when the example PHP source didn't meet our needs. The > company I work for agreed to release it under the terms of the Apache License. > This version is slightly different from what I originally linked to on the > dev mailing list. I've incorporated feedback from Yonik and "hossman" to > simplify the client and only accept one response format (JSON currently). > When Solr 1.3 is released the client can be updated to use the PHP or > Serialized PHP response writer. > example usage from my original mailing list post: > require_once('Solr/Service.php'); > $start = microtime(true); > $solr = new Solr_Service(); //Or explicitly new Solr_Service('localhost', > 8180, '/solr'); > try > { > $response = $solr->search('solr', 0, 10, > array(/* you can include other parameters here */)); > echo 'search returned with status = ', > $response->responseHeader->status, > ' and took ', microtime(true) - $start, ' seconds', "\n"; > //here's how you would access results > //Notice that I've mapped the values by name into a tree of stdClass > objects > //and arrays (actually, most of this is done by json_decode ) > if ($response->response->numFound > 0) > { > $doc_number = $response->response->start; > foreach ($response->response->docs as $doc) > { > $doc_number++; > echo $doc_number, ': ', $doc->text, "\n"; > } > } > //for the purposes of seeing the available structure of the response > //NOTE: Solr_Response::_parsedData is lazy loaded, so a print_r on > the response before > //any values are accessed may result in different behavior (in case > //anyone has some troubles debugging) > //print_r($response); > } > catch (Exception $e) > { > echo $e->getMessage(), "\n"; > } > ?> -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
ACL security in Solr
Hi, I am about to start my master thesis project at the company Findwise (http://www.findwise.se) in Stockholm. The thesis will involve Solr, and indirectly Lucene. My goal is to implement ACL security into Solr, possibly through a plugin? I would like to know your thoughts on this. Has it already been done or is someone currently working on something similar? Do you have any thoughts on the architectural design and which data sources that would be the easiest to start with? I am also considering whether to implement early binding, late binding or both (Information on early, late binding: http://www.e2conf.com/archive/presentations/downloads/FO45_Bennett.pdf). Since I don't have that much time I might have to settle with implementing only one. Any thoughts on which of these methods to prefer? Best regards, Anders Rask
[jira] Updated: (SOLR-236) Field collapsing
[ https://issues.apache.org/jira/browse/SOLR-236?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] dieter grad updated SOLR-236: - Attachment: collapsing-patch-to-1.3.0-dieter.patch I had to make a patch to fix two issues that we needed for our system. I am not used to this code, so maybe someone can pick this patch and make it something useful for everybody. The fixes are: 1) When collapsing.facet=before, only the collapsed documents are returned (and not the whole collection). 2) When collapsing is normal, the selected sort order is preserved by returning the first document of the collapsed group. For example, if the values of the collapsing field are: 1) Y 2) X 3) X 4) Y 5)X 6)Z the documents returned are 1, 2 and 6, in that order. So, for example, if you sort by price ascending, you will get the result sorted by price, where each item is the cheapest item of its collapsed group. > Field collapsing > > > Key: SOLR-236 > URL: https://issues.apache.org/jira/browse/SOLR-236 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Emmanuel Keller > Fix For: 1.4 > > Attachments: collapsing-patch-to-1.3.0-dieter.patch, > collapsing-patch-to-1.3.0-ivan.patch, collapsing-patch-to-1.3.0-ivan_2.patch, > collapsing-patch-to-1.3.0-ivan_3.patch, > field-collapsing-extended-592129.patch, field_collapsing_1.1.0.patch, > field_collapsing_1.3.patch, field_collapsing_dsteigerwald.diff, > field_collapsing_dsteigerwald.diff, field_collapsing_dsteigerwald.diff, > SOLR-236-FieldCollapsing.patch, SOLR-236-FieldCollapsing.patch, > SOLR-236-FieldCollapsing.patch, solr-236.patch > > > This patch include a new feature called "Field collapsing". > "Used in order to collapse a group of results with similar value for a given > field to a single entry in the result set. Site collapsing is a special case > of this, where all results for a given web site is collapsed into one or two > entries in the result set, typically with an associated "more documents from > this site" link. See also Duplicate detection." > http://www.fastsearch.com/glossary.aspx?m=48&amid=299 > The implementation add 3 new query parameters (SolrParams): > "collapse.field" to choose the field used to group results > "collapse.type" normal (default value) or adjacent > "collapse.max" to select how many continuous results are allowed before > collapsing > TODO (in progress): > - More documentation (on source code) > - Test cases > Two patches: > - "field_collapsing.patch" for current development version > - "field_collapsing_1.1.0.patch" for Solr-1.1.0 > P.S.: Feedback and misspelling correction are welcome ;-) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: ACL security in Solr
Anders, Drupal has an ACL implementation, called apachesolr_nodeaccess. It is an integration of Drupal's ACLs into Solr, and might be interesting for you to look at: http://cvs.drupal.org/viewvc.py/drupal/contributions/modules/apachesolr/contrib/apachesolr_nodeaccess/?pathrev=DRUPAL-6--1 http://drupal.org/project/apachesolr http://drupal.org/node/230383 Robert Douglass The RobsHouse.net Newsletter: http://robshouse.net/newsletter/robshousenet-newsletter Follow me on Twitter: http://twitter.com/robertDouglass On Jan 29, 2009, at 3:22 PM, Anders Rask wrote: Hi, I am about to start my master thesis project at the company Findwise (http://www.findwise.se) in Stockholm. The thesis will involve Solr, and indirectly Lucene. My goal is to implement ACL security into Solr, possibly through a plugin? I would like to know your thoughts on this. Has it already been done or is someone currently working on something similar? Do you have any thoughts on the architectural design and which data sources that would be the easiest to start with? I am also considering whether to implement early binding, late binding or both (Information on early, late binding: http://www.e2conf.com/archive/presentations/downloads/FO45_Bennett.pdf) . Since I don't have that much time I might have to settle with implementing only one. Any thoughts on which of these methods to prefer? Best regards, Anders Rask
[jira] Updated: (SOLR-991) Add Detail To Configuration XML Parsing Error Messages
[ https://issues.apache.org/jira/browse/SOLR-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-991: --- Attachment: SOLR-991.patch Patch to log the name of the file (SolrConfig.xml in this case) and then re-throw the exception. Solr already logs the start of schema parsing therefore it is easy to identify malformed schema.xml files. Unfortunately, the parser does not give us the exact position of the error. I'll commit this shortly. > Add Detail To Configuration XML Parsing Error Messages > -- > > Key: SOLR-991 > URL: https://issues.apache.org/jira/browse/SOLR-991 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 > Environment: jdk 1.6+, Tomcat 5.x, 6.x >Reporter: Michael Henson >Priority: Minor > Attachments: SOLR-991.patch > > > When there is a parsing error in configuration xml files, the error message > does not specify which file was being processed or what line caused the parse > failure: > === snip === > [Fatal Error] :33:54: The string "--" is not permitted within comments. > Jan 27, 2009 6:07:54 PM org.apache.solr.common.SolrException log > SEVERE: org.xml.sax.SAXParseException: The string "--" is not permitted > within comments. > at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown > Source) > at > com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown > Source) > at javax.xml.parsers.DocumentBuilder.parse(Unknown Source) > at org.apache.solr.core.Config.(Config.java:104) > at org.apache.solr.core.SolrConfig.(SolrConfig.java:111) > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:338) > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:217) > === snip === > As a result, finding minor typos in the config files can take quite a bit of > user time. In this case the specific error was an extraneous space in the > closing xml comment tag, "-- >" instead of "-->". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-991) Add Detail To Configuration XML Parsing Error Messages
[ https://issues.apache.org/jira/browse/SOLR-991?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar resolved SOLR-991. Resolution: Fixed Fix Version/s: 1.4 Assignee: Shalin Shekhar Mangar Committed revision 738916. Thanks Michael! > Add Detail To Configuration XML Parsing Error Messages > -- > > Key: SOLR-991 > URL: https://issues.apache.org/jira/browse/SOLR-991 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 > Environment: jdk 1.6+, Tomcat 5.x, 6.x >Reporter: Michael Henson >Assignee: Shalin Shekhar Mangar >Priority: Minor > Fix For: 1.4 > > Attachments: SOLR-991.patch > > > When there is a parsing error in configuration xml files, the error message > does not specify which file was being processed or what line caused the parse > failure: > === snip === > [Fatal Error] :33:54: The string "--" is not permitted within comments. > Jan 27, 2009 6:07:54 PM org.apache.solr.common.SolrException log > SEVERE: org.xml.sax.SAXParseException: The string "--" is not permitted > within comments. > at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(Unknown > Source) > at > com.sun.org.apache.xerces.internal.jaxp.DocumentBuilderImpl.parse(Unknown > Source) > at javax.xml.parsers.DocumentBuilder.parse(Unknown Source) > at org.apache.solr.core.Config.(Config.java:104) > at org.apache.solr.core.SolrConfig.(SolrConfig.java:111) > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:338) > at org.apache.solr.core.CoreContainer.load(CoreContainer.java:217) > === snip === > As a result, finding minor typos in the config files can take quite a bit of > user time. In this case the specific error was an extraneous space in the > closing xml comment tag, "-- >" instead of "-->". -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: trunk test failure
Mark Miller wrote: Anyone else seeing the function query test failing on trunk? - Mark Okay, I tried building trunk lucene myself, and after putting that in, the function query test passed. Perhaps an odd Lucene build went in? I'm running on Ubuntu 8.10 and using opendJDK 1.6 and Sun 1.5. - Mark
Re: trunk test failure
On Thu, Jan 29, 2009 at 12:07 PM, Mark Miller wrote: > Mark Miller wrote: >> >> Anyone else seeing the function query test failing on trunk? >> >> - Mark > > Okay, I tried building trunk lucene myself, and after putting that in, the > function query test passed. Perhaps an odd Lucene build went in? The previous lucene nightly had failed (on an svn tag lookup), so I built lucene myself (and all tests did pass). I've tried multiple times, and I can't get that same test to fail (WinXP). Very strange. Anyway, since the latest lucene nightly did pass, I'll update to that. Hopefully that should fix things. -Yonik
Re: trunk test failure
Except... the only reason (I think) that the Lucene build failed was because I had switched the back-compat test to check out an https:// URL instead of http:// (the build got hung asking whether you trust that host because its cert was suspect) so I switched it back... and I'm not sure why that Solr test failed! Hmmm... Mike Yonik Seeley wrote: On Thu, Jan 29, 2009 at 12:07 PM, Mark Miller wrote: Mark Miller wrote: Anyone else seeing the function query test failing on trunk? - Mark Okay, I tried building trunk lucene myself, and after putting that in, the function query test passed. Perhaps an odd Lucene build went in? The previous lucene nightly had failed (on an svn tag lookup), so I built lucene myself (and all tests did pass). I've tried multiple times, and I can't get that same test to fail (WinXP). Very strange. Anyway, since the latest lucene nightly did pass, I'll update to that. Hopefully that should fix things. -Yonik
Re: trunk test failure
On Thu, Jan 29, 2009 at 12:17 PM, Michael McCandless wrote: > > Except... the only reason (I think) that the Lucene build failed was because > I had switched the back-compat test to check out an https:// URL instead of > http:// (the build got hung asking whether you trust that host because its > cert was suspect) so I switched it back... and I'm not sure why that > Solr test failed! Hmmm... Right... it doesn't look like a Lucene bug... except if there is something weird in the build that doesn't quite work on Windows. I built lucene with java 1.5.0_16. Could have been a subtle compiler bug, or a bit flip somewhere that only affected Windows, or the bytecode output from my compiler tickled a hotspot bug on Unix Anyway, I'm testing with the latest nightly build lucene libs now and will check in if they pass (for me). -Yonik > Mike > > Yonik Seeley wrote: > >> On Thu, Jan 29, 2009 at 12:07 PM, Mark Miller >> wrote: >>> >>> Mark Miller wrote: Anyone else seeing the function query test failing on trunk? - Mark >>> >>> Okay, I tried building trunk lucene myself, and after putting that in, >>> the >>> function query test passed. Perhaps an odd Lucene build went in? >> >> The previous lucene nightly had failed (on an svn tag lookup), so I >> built lucene myself (and all tests did pass). >> I've tried multiple times, and I can't get that same test to fail >> (WinXP). Very strange. >> >> Anyway, since the latest lucene nightly did pass, I'll update to that. >> Hopefully that should fix things. >> >> -Yonik > >
Re: trunk test failure
On Thu, Jan 29, 2009 at 10:43 PM, Yonik Seeley wrote: > On Thu, Jan 29, 2009 at 12:07 PM, Mark Miller > wrote: > > Mark Miller wrote: > >> > >> Anyone else seeing the function query test failing on trunk? > >> > >> - Mark > > > > Okay, I tried building trunk lucene myself, and after putting that in, > the > > function query test passed. Perhaps an odd Lucene build went in? > > The previous lucene nightly had failed (on an svn tag lookup), so I > built lucene myself (and all tests did pass). > I've tried multiple times, and I can't get that same test to fail > (WinXP). Very strange. The FunctionQuery#singleTest fails for me on Ubuntu 8.10 with Sun JDK. java version "1.6.0_11" Java(TM) SE Runtime Environment (build 1.6.0_11-b03) Java HotSpot(TM) Server VM (build 11.0-b16, mixed mode) -- Regards, Shalin Shekhar Mangar.
Re: trunk test failure
On Thu, Jan 29, 2009 at 11:13 PM, Shalin Shekhar Mangar < shalinman...@gmail.com> wrote: > > The FunctionQuery#singleTest fails for me on Ubuntu 8.10 with Sun JDK. > That should have been FunctionQuery#testExternalField on singleTest(field, "\0", answers) -- Regards, Shalin Shekhar Mangar.
[jira] Updated: (SOLR-966) Enhance the map() function to take in multiple tuples
[ https://issues.apache.org/jira/browse/SOLR-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-966: Attachment: SOLR-966.patch decided to go w/ shalin's suggestion . added just a default value. The last value is optional. if not present ,the field value is used as default. > Enhance the map() function to take in multiple tuples > - > > Key: SOLR-966 > URL: https://issues.apache.org/jira/browse/SOLR-966 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul > Fix For: 1.4 > > Attachments: SOLR-966.patch > > > The map function currently takes in only one min,max target. This makes it > impossible to map it to multiple values . > It should be possible to pass on multiple sets of values > example > {code} > map(x,0,0,10,1,1,20,2,2,50) > {code} > it should allow an n number of float values (where n%3 = 0) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: trunk test failure
OK, I've committed the latest lucene nightly. I'm getting intermittent failures in SolrExampleStreamingTest but I doubt it's related to a lucene version. I'm getting failures in TestReplicationHandler: ERRORunknown_field_newname Anyone else? -Yonik On Thu, Jan 29, 2009 at 12:45 PM, Shalin Shekhar Mangar wrote: > On Thu, Jan 29, 2009 at 11:13 PM, Shalin Shekhar Mangar < > shalinman...@gmail.com> wrote: > >> >> The FunctionQuery#singleTest fails for me on Ubuntu 8.10 with Sun JDK. >> > > That should have been FunctionQuery#testExternalField on singleTest(field, > "\0", answers) > > -- > Regards, > Shalin Shekhar Mangar. >
[jira] Assigned: (SOLR-966) Enhance the map() function to take in multiple tuples
[ https://issues.apache.org/jira/browse/SOLR-966?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar reassigned SOLR-966: -- Assignee: Shalin Shekhar Mangar > Enhance the map() function to take in multiple tuples > - > > Key: SOLR-966 > URL: https://issues.apache.org/jira/browse/SOLR-966 > Project: Solr > Issue Type: Improvement >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: SOLR-966.patch > > > The map function currently takes in only one min,max target. This makes it > impossible to map it to multiple values . > It should be possible to pass on multiple sets of values > example > {code} > map(x,0,0,10,1,1,20,2,2,50) > {code} > it should allow an n number of float values (where n%3 = 0) -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-995) TestJmxMonitoredMap hangs
TestJmxMonitoredMap hangs - Key: SOLR-995 URL: https://issues.apache.org/jira/browse/SOLR-995 Project: Solr Issue Type: Bug Environment: CentOS5-64, Java 1.6.0_11, locked down server, most incoming and outgoing ports closed. Reporter: Yonik Seeley Priority: Minor TestJmxMonitoredMap test hangs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-995) TestJmxMonitoredMap hangs
[ https://issues.apache.org/jira/browse/SOLR-995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668572#action_12668572 ] Yonik Seeley commented on SOLR-995: --- Thread dump for the main thread... perhaps the hang is because incoming and outgoing ports are closed via iptables? {code} [junit] "main" prio=10 tid=0x5cf0dc00 nid=0x60a4 runnable [0x40a74000..0x40a76ed0] [junit]java.lang.Thread.State: RUNNABLE [junit] at java.net.PlainSocketImpl.socketConnect(Native Method) [junit] at java.net.PlainSocketImpl.doConnect(PlainSocketImpl.java:333) [junit] - locked <0x2aab5a75d9c8> (a java.net.SocksSocketImpl) [junit] at java.net.PlainSocketImpl.connectToAddress(PlainSocketImpl.java:195) [junit] at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:182) [junit] at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:366) [junit] at java.net.Socket.connect(Socket.java:519) [junit] at java.net.Socket.connect(Socket.java:469) [junit] at java.net.Socket.(Socket.java:366) [junit] at java.net.Socket.(Socket.java:180) [junit] at sun.rmi.transport.proxy.RMIDirectSocketFactory.createSocket(RMIDirectSocketFactory.java:22) [junit] at sun.rmi.transport.proxy.RMIMasterSocketFactory.createSocket(RMIMasterSocketFactory.java:128) [junit] at sun.rmi.transport.tcp.TCPEndpoint.newSocket(TCPEndpoint.java:595) [junit] at sun.rmi.transport.tcp.TCPChannel.createConnection(TCPChannel.java:198) [junit] at sun.rmi.transport.tcp.TCPChannel.newConnection(TCPChannel.java:184) [junit] at sun.rmi.server.UnicastRef.newCall(UnicastRef.java:322) [junit] at sun.rmi.registry.RegistryImpl_Stub.bind(Unknown Source) [junit] at com.sun.jndi.rmi.registry.RegistryContext.bind(RegistryContext.java:120) [junit] at com.sun.jndi.toolkit.url.GenericURLContext.bind(GenericURLContext.java:208) [junit] at javax.naming.InitialContext.bind(InitialContext.java:400) [junit] at javax.management.remote.rmi.RMIConnectorServer.bind(RMIConnectorServer.java:625) [junit] at javax.management.remote.rmi.RMIConnectorServer.start(RMIConnectorServer.java:412) [junit] - locked <0x2aaab3618768> (a javax.management.remote.rmi.RMIConnectorServer) [junit] at org.apache.solr.core.JmxMonitoredMap.(JmxMonitoredMap.java:95) [junit] at org.apache.solr.core.TestJmxMonitoredMap.setUp(TestJmxMonitoredMap.java:69) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) [junit] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) [junit] at java.lang.reflect.Method.invoke(Method.java:597) [junit] at org.junit.internal.runners.BeforeAndAfterRunner.invokeMethod(BeforeAndAfterRunner.java:74) [junit] at org.junit.internal.runners.BeforeAndAfterRunner.runBefores(BeforeAndAfterRunner.java:50) [junit] at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:33) [junit] at org.junit.internal.runners.TestMethodRunner.runMethod(TestMethodRunner.java:75) [junit] at org.junit.internal.runners.TestMethodRunner.run(TestMethodRunner.java:45) [junit] at org.junit.internal.runners.TestClassMethodsRunner.invokeTestMethod(TestClassMethodsRunner.java:66) [junit] at org.junit.internal.runners.TestClassMethodsRunner.run(TestClassMethodsRunner.java:35) [junit] at org.junit.internal.runners.TestClassRunner$1.runUnprotected(TestClassRunner.java:42) [junit] at org.junit.internal.runners.BeforeAndAfterRunner.runProtected(BeforeAndAfterRunner.java:34) [junit] at org.junit.internal.runners.TestClassRunner.run(TestClassRunner.java:52) [junit] at junit.framework.JUnit4TestAdapter.run(JUnit4TestAdapter.java:32) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.run(JUnitTestRunner.java:420) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.launch(JUnitTestRunner.java:911) [junit] at org.apache.tools.ant.taskdefs.optional.junit.JUnitTestRunner.main(JUnitTestRunner.java:768) {code} > TestJmxMonitoredMap hangs > - > > Key: SOLR-995 > URL: https://issues.apache.org/jira/browse/SOLR-995 > Project: Solr > Issue Type: Bug > Environment: CentOS5-64, Java 1.6.0_11, locked down server, most > incoming and outgoing ports closed. >Reporter: Yonik Seeley >Priority: Minor > > TestJmxMonitoredMap test hangs. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue onli
[jira] Updated: (SOLR-899) NullPointerException in ClientUtils.writeXML on NULL field value
[ https://issues.apache.org/jira/browse/SOLR-899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Todd Feak updated SOLR-899: --- Priority: Minor (was: Trivial) > NullPointerException in ClientUtils.writeXML on NULL field value > > > Key: SOLR-899 > URL: https://issues.apache.org/jira/browse/SOLR-899 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.3 >Reporter: Todd Feak >Priority: Minor > > This exception occurs if I have a field in a document with a null value. > java.lang.NullPointerException > at > org.apache.solr.client.solrj.util.ClientUtils.writeXML(ClientUtils.java:117) > at > org.apache.solr.client.solrj.request.UpdateRequest.getXML(UpdateRequest.java:169) > at > org.apache.solr.client.solrj.request.UpdateRequest.getContentStreams(UpdateRequest.java:160) > ... > Previous versions of this class had a null check, which was subsequently > removed. I have no problem with removing the previous null-check, as it > seemed to "hide" a programming mistake (i.e. null values). However, I think > that the exception that occurs here could at least be a bit more informative. > Performing a null check and then throwing some sort of RuntimeException or > IOException with a descriptive message would be very helpful. Such as > "Failure, NULL value for field named[foo] detected". > Alternatively, I think that an argument could be made that this NULL > shouldn't have been allowed in the document in the first place. If that is > the case, then NULL checks with similarly helpful messages could be performed > upstream of this issue. I personally lean this way, as I prefer to find a > programming mistake closer to the source of the issue. It allows me to find > out exactly where the NULL was inserted in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-899) NullPointerException in ClientUtils.writeXML on NULL field value
[ https://issues.apache.org/jira/browse/SOLR-899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668646#action_12668646 ] Todd Feak commented on SOLR-899: I dug a bit more on this bug. I think the null check needs to be put back into ClientUtils.writeXML that was previously there. This bit of code for( Object v : field ) { if (v instanceof Date) { v = fmtThreadLocal.get().format( (Date)v ); } if( boost != 1.0f ) { XML.writeXML(writer, "field", v.toString(), "name", name, "boost", boost ); } else { XML.writeXML(writer, "field", v.toString(), "name", name ); } // only write the boost for the first multi-valued field // otherwise, the used boost is the product of all the boost values boost = 1.0f; } is vulnerable to an NPE if the value of a field is null. The value of a field will only come back as null for a multi-valued field containing a null. This cannot be completely guarded against at the SolrInputDocument level, as it's impossible to tell if a field is multi-valued or not the first time it is put in. Patch coming soon. > NullPointerException in ClientUtils.writeXML on NULL field value > > > Key: SOLR-899 > URL: https://issues.apache.org/jira/browse/SOLR-899 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 1.3 >Reporter: Todd Feak >Priority: Minor > > This exception occurs if I have a field in a document with a null value. > java.lang.NullPointerException > at > org.apache.solr.client.solrj.util.ClientUtils.writeXML(ClientUtils.java:117) > at > org.apache.solr.client.solrj.request.UpdateRequest.getXML(UpdateRequest.java:169) > at > org.apache.solr.client.solrj.request.UpdateRequest.getContentStreams(UpdateRequest.java:160) > ... > Previous versions of this class had a null check, which was subsequently > removed. I have no problem with removing the previous null-check, as it > seemed to "hide" a programming mistake (i.e. null values). However, I think > that the exception that occurs here could at least be a bit more informative. > Performing a null check and then throwing some sort of RuntimeException or > IOException with a descriptive message would be very helpful. Such as > "Failure, NULL value for field named[foo] detected". > Alternatively, I think that an argument could be made that this NULL > shouldn't have been allowed in the document in the first place. If that is > the case, then NULL checks with similarly helpful messages could be performed > upstream of this issue. I personally lean this way, as I prefer to find a > programming mistake closer to the source of the issue. It allows me to find > out exactly where the NULL was inserted in the first place. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: trunk test failure
The strangeness continues... TestFunctionQuery always passes for me, and always fails for others. Apparently, when Mark compiles trunk himself, the result passes again. Time to fire up vmware to see if I can get this to fail... -Yonik On Thu, Jan 29, 2009 at 1:34 PM, Yonik Seeley wrote: > OK, I've committed the latest lucene nightly. > > I'm getting intermittent failures in SolrExampleStreamingTest > but I doubt it's related to a lucene version. > > I'm getting failures in TestReplicationHandler: > ERRORunknown_field_newname > Anyone else? > > -Yonik > > > > On Thu, Jan 29, 2009 at 12:45 PM, Shalin Shekhar Mangar > wrote: >> On Thu, Jan 29, 2009 at 11:13 PM, Shalin Shekhar Mangar < >> shalinman...@gmail.com> wrote: >> >>> >>> The FunctionQuery#singleTest fails for me on Ubuntu 8.10 with Sun JDK. >>> >> >> That should have been FunctionQuery#testExternalField on singleTest(field, >> "\0", answers) >> >> -- >> Regards, >> Shalin Shekhar Mangar. >> >
[jira] Commented: (SOLR-839) XML Query Parser support
[ https://issues.apache.org/jira/browse/SOLR-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668728#action_12668728 ] Karl Wettin commented on SOLR-839: -- The patch does not parse UTF8. Not sure if it is supposed to do that by default? Below is my version of the class. It needs to pick up the contentEncoding from the properties, but I'm not sure where and how. {code:java} import org.apache.solr.common.params.SolrParams; import org.apache.solr.common.util.NamedList; import org.apache.solr.request.SolrQueryRequest; import org.apache.solr.search.QParserPlugin; import org.apache.solr.search.QParser; import org.apache.lucene.search.Query; import org.apache.lucene.queryParser.ParseException; import org.apache.lucene.xmlparser.CorePlusExtensionsParser; import org.apache.lucene.xmlparser.ParserException; import java.io.ByteArrayInputStream; import java.io.UnsupportedEncodingException; public class XmlQParserPlugin extends QParserPlugin { private String contentEncoding = "UTF8"; public void init(NamedList args) { } public QParser createParser(String qstr, SolrParams localParams, SolrParams params, SolrQueryRequest req) { return new XmlQParser(qstr, localParams, params, req); } class XmlQParser extends QParser { public XmlQParser(String qstr, SolrParams localParams, SolrParams params, SolrQueryRequest req) { super(qstr, localParams, params, req); } public Query parse() throws ParseException { CorePlusExtensionsParser parser = new CorePlusExtensionsParser(getReq().getSchema().getQueryAnalyzer(), getReq().getSchema().getSolrQueryParser(null)); try { return parser.parse(new ByteArrayInputStream(getString().getBytes(contentEncoding))); } catch (UnsupportedEncodingException e) { throw new ParseException(e.getMessage()); } catch (ParserException e) { throw new ParseException(e.getMessage()); } } } } {code} > XML Query Parser support > > > Key: SOLR-839 > URL: https://issues.apache.org/jira/browse/SOLR-839 > Project: Solr > Issue Type: New Feature > Components: search >Affects Versions: 1.3 >Reporter: Erik Hatcher >Assignee: Erik Hatcher > Fix For: 1.4 > > Attachments: lucene-xml-query-parser-2.4-dev.jar, SOLR-839.patch > > > Lucene contrib includes a query parser that is able to create the > full-spectrum of Lucene queries, using an XML data structure. > This patch adds "xml" query parser support to Solr. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-839) XML Query Parser support
[ https://issues.apache.org/jira/browse/SOLR-839?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12668745#action_12668745 ] Karl Wettin commented on SOLR-839: -- There seems to be a bug here somewhere. As the xml query hit 6-7 kb data or 60-70 clauses i start getting connection resets. If I switch to BoostingTermQuery then it seems to indicate it has to do with the amount of xml data and not to do with number of clauses. I get nothing in my Solr log about this failing request. {code:java} SolrQuery solrQuery = new SolrQuery(); solrQuery.add("fl", "score"); solrQuery.add("defType", "xml"); StringBuilder xml = new StringBuilder(1); xml.append(""); for (int i = 0; i < 1; i++) { xml.append(""); xml.append(""); xml.append("foo"); xml.append(""); xml.append(""); solrQuery.setQuery(xml.toString() + ""); System.out.println(i + "\t" + solrQuery.getQuery().length()); try { SearchService.getInstance().getSolr().query(solrQuery); } catch (SolrServerException e) { if (e.getCause() != null && e.getCause().getCause() != null && e.getCause().getCause() instanceof java.net.SocketException) { throw e; } } } {code} {code} 0 121 1 192 2 263 3 334 4 405 5 476 6 547 7 618 8 689 9 760 10 831 11 902 12 973 13 1044 14 1115 15 1186 16 1257 17 1328 18 1399 19 1470 20 1541 21 1612 22 1683 23 1754 24 1825 25 1896 26 1967 27 2038 28 2109 29 2180 30 2251 31 2322 32 2393 33 2464 34 2535 35 2606 36 2677 37 2748 38 2819 39 2890 40 2961 41 3032 42 3103 43 3174 44 3245 45 3316 46 3387 47 3458 48 3529 49 3600 50 3671 51 3742 52 3813 53 3884 54 3955 55 4026 56 4097 57 4168 58 4239 59 4310 60 4381 61 4452 62 4523 63 4594 64 4665 65 4736 66 4807 67 4878 68 4949 69 5020 70 5091 71 5162 72 5233 73 5304 74 5375 75 5446 76 5517 2097 [main] INFO org.apache.commons.httpclient.HttpMethodDirector - I/O exception (org.apache.commons.httpclient.NoHttpResponseException) caught when processing request: The server localhost failed to respond 2098 [main] INFO org.apache.commons.httpclient.HttpMethodDirector - Retrying request 2100 [main] INFO org.apache.commons.httpclient.HttpMethodDirector - I/O exception (org.apache.commons.httpclient.NoHttpResponseException) caught when processing request: The server localhost failed to respond 2100 [main] INFO org.apache.commons.httpclient.HttpMethodDirector - Retrying request 2102 [main] INFO org.apache.commons.httpclient.HttpMethodDirector - I/O exception (org.apache.commons.httpclient.NoHttpResponseException) caught when processing request: The server localhost failed to respond 2102 [main] INFO org.apache.commons.httpclient.HttpMethodDirector - Retrying request 77 5588 2108 [main] INFO org.apache.commons.httpclient.HttpMethodDirector - I/O exception (org.apache.commons.httpclient.NoHttpResponseException) caught when processing request: The server localhost failed to respond 2109 [main] INFO org.apache.commons.httpclient.HttpMethodDirector - Retrying request org.apache.solr.client.solrj.SolrServerException: Error executing query at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:96) at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:109) at se.hundraartonetthundra.TestSearch.test(TestSearch.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:81) at com.intellij.rt.junit4.Junit4ClassSuite.run(Junit4ClassSuite.java:99) at com.intellij.rt.execution.junit.JUnitStarter.main(JUnitStarter.java:40) Caused by: org.apache.solr.client.solrj.SolrServerException: java.net.SocketException: Connection reset at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:391) at org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:183) at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:90) ... 22 more Caused by: java.net.SocketException: Connection reset at java.net.SocketInputStream.read(SocketInputStream.java:168) at java.io.BufferedInputStream.fill(BufferedInpu
Re: trunk test failure
Added a note about the cause of this in https://issues.apache.org/jira/browse/LUCENE-1478 -Yonik On Thu, Jan 29, 2009 at 7:49 PM, Yonik Seeley wrote: > The strangeness continues... TestFunctionQuery always passes for me, > and always fails for others. > Apparently, when Mark compiles trunk himself, the result passes again. > > Time to fire up vmware to see if I can get this to fail... > > -Yonik > > On Thu, Jan 29, 2009 at 1:34 PM, Yonik Seeley wrote: >> OK, I've committed the latest lucene nightly. >> >> I'm getting intermittent failures in SolrExampleStreamingTest >> but I doubt it's related to a lucene version. >> >> I'm getting failures in TestReplicationHandler: >> ERRORunknown_field_newname >> Anyone else? >> >> -Yonik >> >> >> >> On Thu, Jan 29, 2009 at 12:45 PM, Shalin Shekhar Mangar >> wrote: >>> On Thu, Jan 29, 2009 at 11:13 PM, Shalin Shekhar Mangar < >>> shalinman...@gmail.com> wrote: >>> The FunctionQuery#singleTest fails for me on Ubuntu 8.10 with Sun JDK. >>> >>> That should have been FunctionQuery#testExternalField on singleTest(field, >>> "\0", answers) >>> >>> -- >>> Regards, >>> Shalin Shekhar Mangar. >>> >> >