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. >>> >> >
