Re: Outstanding issues for 3.0.3
Go ahead with contrib and tests, ill resume with core and coordinate further later On Jul 27, 2012 7:04 PM, Christopher Currens currens.ch...@gmail.com wrote: I've got resharper and can help with that if you'd like to coordinate it. I can take a one or some of the contrib projects or part of the main library, or *shudder* the any of the test libraries. The code has needed come cleaning up for a while and some of the clean up work is an optimization some levels, so I'm definitely okay with spending some time doing that. I'm okay with waiting longer as long as something is getting done. Thanks, Christopher On Fri, Jul 27, 2012 at 9:00 AM, Itamar Syn-Hershko ita...@code972.com wrote: The cleanup consists mainly of going file by file with ReSharper and trying to get them as green as possible. Making a lot of fields readonly, removing unused vars and stuff like that. There are still loads of files left. I was also hoping to get to updating the spatial module with some recent updates, and to also support polygon searches. But that may take a bit more time, so it's really up to you guys (or we can open a vote for it). On Fri, Jul 27, 2012 at 6:35 PM, Christopher Currens currens.ch...@gmail.com wrote: Itamar, Where do we stand on the clean up now? Is there anything in particular that you're doing that you'd like help with? I have some free time today and am eager to get this version released. Thanks, Christopher On Sat, Jul 21, 2012 at 1:02 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, I'll hold off a bit. Date: Sat, 21 Jul 2012 22:59:32 +0300 Subject: Re: Outstanding issues for 3.0.3 From: ita...@code972.com To: lucene-net-u...@lucene.apache.org CC: lucene-net-dev@lucene.apache.org Actually there was some clean up work I started doing and would want to complete, and also sign off on the suspected corruption issue we raised. I'm afraid I won't have much time this week to properly do all that, but I'll keep you posted. On Sat, Jul 21, 2012 at 10:20 PM, Prescott Nasser geobmx...@hotmail.com wrote: Alright, latest patch fixed what could be done with the cls issues at present. With that, I think we are ready to roll with a release. If people could please take some time to run all the test as well as whatever other tests they might run. We've had some issues with tests only happening on some systems so I want to make sure we have those bases covered. Unless there is anything else that should be done, I'll leave every one a week to run their tests. Next saturday I will tag the trunk and cut a release with both 3.5 and 4.0 binaries. Great work everyone. ~P Date: Mon, 9 Jul 2012 18:02:30 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I can set a different build target, but I can't set the actual framework to 3.5 without doing it for all build configurations. On top of that, 3.5 needs System.Core to be referenced, which is done automatically in .NET 4 (I'm not sure if MSBuild v4 does it automatically?). I did kinda get it working by putting a TargetFrameworkVersion tag of 4.0 in Debug and Release configurations and 3.5 in Debug 3.5 and Release 3.5 configurations, but that's a little...well, difficult to maintain by hand since visual studio doesn't allow you to set different framework versions per configuration, and visual studio seemed to be having trouble with references, since both frameworks were being referenced. On Mon, Jul 9, 2012 at 5:57 PM, Prescott Nasser geobmx...@hotmail.com wrote: What do you mean doesn't work at the project level? I created a different build target NET35 and then we had Debug and Release still, that seemed to work for me. But I feel like I'm missing something in your explaination. Good work though! Date: Mon, 9 Jul 2012 17:51:36 -0700 Subject: Re: Outstanding issues for 3.0.3 From: currens.ch...@gmail.com To: lucene-net-dev@lucene.apache.org I've got it working, compiling and all test passing...The only caveat is that I'm not sure the best way to multi-target. It doesn't really work on a project level, so you'd have to create two separate projects, one for .NET 4 and the other for 3.5. To aid me, I wrote a small tool that creates copies of all of the 4.0 projects and solutions to work against the
[jira] [Updated] (LUCENE-3312) Break out StorableField from IndexableField
[ https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nikola Tankovic updated LUCENE-3312: Attachment: lucene-3312-patch-08.patch Patch 08: Everything compiles, Lucene tests pass except for 'TestQualityRun' (I'm struggling with this one). Solr tests are yet to be fixed. Uwe, you can merge in the trunk, so I can continue. Break out StorableField from IndexableField --- Key: LUCENE-3312 URL: https://issues.apache.org/jira/browse/LUCENE-3312 Project: Lucene - Core Issue Type: Improvement Components: core/index Reporter: Michael McCandless Assignee: Nikola Tankovic Labels: gsoc2012, lucene-gsoc-12 Fix For: Field Type branch Attachments: lucene-3312-patch-01.patch, lucene-3312-patch-02.patch, lucene-3312-patch-03.patch, lucene-3312-patch-04.patch, lucene-3312-patch-05.patch, lucene-3312-patch-06.patch, lucene-3312-patch-07.patch, lucene-3312-patch-08.patch In the field type branch we have strongly decoupled Document/Field/FieldType impl from the indexer, by having only a narrow API (IndexableField) passed to IndexWriter. This frees apps up use their own documents instead of the user-space impls we provide in oal.document. Similarly, with LUCENE-3309, we've done the same thing on the doc/field retrieval side (from IndexReader), with the StoredFieldsVisitor. But, maybe we should break out StorableField from IndexableField, such that when you index a doc you provide two Iterables -- one for the IndexableFields and one for the StorableFields. Either can be null. One downside is possible perf hit for fields that are both indexed stored (ie, we visit them twice, lookup their name in a hash twice, etc.). But the upside is a cleaner separation of concerns in API -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4268) Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader
Uwe Schindler created LUCENE-4268: - Summary: Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader Key: LUCENE-4268 URL: https://issues.apache.org/jira/browse/LUCENE-4268 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 4.0, 5.0 Attachments: LUCENE-4268.patch We should rename the class and also fix some bugs: - Class/ClassLoader.getResourceAsStream() returns null when resource not found (which is a Java bug in my opinion) and does not throw IOException. SolrResourceLoader throws IOException, the Lucene example one should do the same. This prevents NPEs everywhere. Improvements: - Add no-arg CTOR that uses context class loader instead a given class. This is more what users want. Resource names must then include package name, of course. We should also provide a second implementation that allows resource names to be full filesystem paths. I think for loading the resources like custom word list, this is the most wanted implementation. Loading of classes would be delegated to ClassLoader (of course). I dont like ResourceLoader also supplying newInstance(), can we remove this for analysis? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4268) Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader
[ https://issues.apache.org/jira/browse/LUCENE-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4268: -- Attachment: LUCENE-4268.patch Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader - Key: LUCENE-4268 URL: https://issues.apache.org/jira/browse/LUCENE-4268 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 4.0, 5.0 Attachments: LUCENE-4268.patch We should rename the class and also fix some bugs: - Class/ClassLoader.getResourceAsStream() returns null when resource not found (which is a Java bug in my opinion) and does not throw IOException. SolrResourceLoader throws IOException, the Lucene example one should do the same. This prevents NPEs everywhere. Improvements: - Add no-arg CTOR that uses context class loader instead a given class. This is more what users want. Resource names must then include package name, of course. We should also provide a second implementation that allows resource names to be full filesystem paths. I think for loading the resources like custom word list, this is the most wanted implementation. Loading of classes would be delegated to ClassLoader (of course). I dont like ResourceLoader also supplying newInstance(), can we remove this for analysis? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4268) Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader
[ https://issues.apache.org/jira/browse/LUCENE-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424316#comment-13424316 ] Uwe Schindler commented on LUCENE-4268: --- The current patch only contains the renamed ClasspathResourceLoader + bug fixes. No filesystem yet. Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader - Key: LUCENE-4268 URL: https://issues.apache.org/jira/browse/LUCENE-4268 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 4.0, 5.0 Attachments: LUCENE-4268.patch We should rename the class and also fix some bugs: - Class/ClassLoader.getResourceAsStream() returns null when resource not found (which is a Java bug in my opinion) and does not throw IOException. SolrResourceLoader throws IOException, the Lucene example one should do the same. This prevents NPEs everywhere. Improvements: - Add no-arg CTOR that uses context class loader instead a given class. This is more what users want. Resource names must then include package name, of course. We should also provide a second implementation that allows resource names to be full filesystem paths. I think for loading the resources like custom word list, this is the most wanted implementation. Loading of classes would be delegated to ClassLoader (of course). I dont like ResourceLoader also supplying newInstance(), can we remove this for analysis? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3312) Break out StorableField from IndexableField
[ https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424319#comment-13424319 ] Uwe Schindler commented on LUCENE-3312: --- Thanks Nikola, I applied your patch in revision: 1366638 The merging is now running. bq. Lucene tests pass except for 'TestQualityRun' (I'm struggling with this one) I think Robert Muir may be able to help you, he already had some comments about this. I will ping him! Break out StorableField from IndexableField --- Key: LUCENE-3312 URL: https://issues.apache.org/jira/browse/LUCENE-3312 Project: Lucene - Core Issue Type: Improvement Components: core/index Reporter: Michael McCandless Assignee: Nikola Tankovic Labels: gsoc2012, lucene-gsoc-12 Fix For: Field Type branch Attachments: lucene-3312-patch-01.patch, lucene-3312-patch-02.patch, lucene-3312-patch-03.patch, lucene-3312-patch-04.patch, lucene-3312-patch-05.patch, lucene-3312-patch-06.patch, lucene-3312-patch-07.patch, lucene-3312-patch-08.patch In the field type branch we have strongly decoupled Document/Field/FieldType impl from the indexer, by having only a narrow API (IndexableField) passed to IndexWriter. This frees apps up use their own documents instead of the user-space impls we provide in oal.document. Similarly, with LUCENE-3309, we've done the same thing on the doc/field retrieval side (from IndexReader), with the StoredFieldsVisitor. But, maybe we should break out StorableField from IndexableField, such that when you index a doc you provide two Iterables -- one for the IndexableFields and one for the StorableFields. Either can be null. One downside is possible perf hit for fields that are both indexed stored (ie, we visit them twice, lookup their name in a hash twice, etc.). But the upside is a cleaner separation of concerns in API -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3312) Break out StorableField from IndexableField
[ https://issues.apache.org/jira/browse/LUCENE-3312?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424320#comment-13424320 ] Uwe Schindler commented on LUCENE-3312: --- Merged up to trunk in revision: 1366643 Break out StorableField from IndexableField --- Key: LUCENE-3312 URL: https://issues.apache.org/jira/browse/LUCENE-3312 Project: Lucene - Core Issue Type: Improvement Components: core/index Reporter: Michael McCandless Assignee: Nikola Tankovic Labels: gsoc2012, lucene-gsoc-12 Fix For: Field Type branch Attachments: lucene-3312-patch-01.patch, lucene-3312-patch-02.patch, lucene-3312-patch-03.patch, lucene-3312-patch-04.patch, lucene-3312-patch-05.patch, lucene-3312-patch-06.patch, lucene-3312-patch-07.patch, lucene-3312-patch-08.patch In the field type branch we have strongly decoupled Document/Field/FieldType impl from the indexer, by having only a narrow API (IndexableField) passed to IndexWriter. This frees apps up use their own documents instead of the user-space impls we provide in oal.document. Similarly, with LUCENE-3309, we've done the same thing on the doc/field retrieval side (from IndexReader), with the StoredFieldsVisitor. But, maybe we should break out StorableField from IndexableField, such that when you index a doc you provide two Iterables -- one for the IndexableFields and one for the StorableFields. Either can be null. One downside is possible perf hit for fields that are both indexed stored (ie, we visit them twice, lookup their name in a hash twice, etc.). But the upside is a cleaner separation of concerns in API -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4268) Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader
[ https://issues.apache.org/jira/browse/LUCENE-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4268: -- Attachment: LUCENE-4268.patch Initial patch including all functionality. FilesystemResourceLoader resolves all resources against a base directory (similar to Solr's loader) and delegates all class lookups and resources not found to a delegate ResourceLoader. The default delegate is ClasspathResourceLoader with context classloader. Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader - Key: LUCENE-4268 URL: https://issues.apache.org/jira/browse/LUCENE-4268 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 4.0, 5.0 Attachments: LUCENE-4268.patch, LUCENE-4268.patch We should rename the class and also fix some bugs: - Class/ClassLoader.getResourceAsStream() returns null when resource not found (which is a Java bug in my opinion) and does not throw IOException. SolrResourceLoader throws IOException, the Lucene example one should do the same. This prevents NPEs everywhere. Improvements: - Add no-arg CTOR that uses context class loader instead a given class. This is more what users want. Resource names must then include package name, of course. We should also provide a second implementation that allows resource names to be full filesystem paths. I think for loading the resources like custom word list, this is the most wanted implementation. Loading of classes would be delegated to ClassLoader (of course). I dont like ResourceLoader also supplying newInstance(), can we remove this for analysis? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4268) Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader
[ https://issues.apache.org/jira/browse/LUCENE-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424322#comment-13424322 ] Chris Male commented on LUCENE-4268: +1 Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader - Key: LUCENE-4268 URL: https://issues.apache.org/jira/browse/LUCENE-4268 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 4.0, 5.0 Attachments: LUCENE-4268.patch, LUCENE-4268.patch We should rename the class and also fix some bugs: - Class/ClassLoader.getResourceAsStream() returns null when resource not found (which is a Java bug in my opinion) and does not throw IOException. SolrResourceLoader throws IOException, the Lucene example one should do the same. This prevents NPEs everywhere. Improvements: - Add no-arg CTOR that uses context class loader instead a given class. This is more what users want. Resource names must then include package name, of course. We should also provide a second implementation that allows resource names to be full filesystem paths. I think for loading the resources like custom word list, this is the most wanted implementation. Loading of classes would be delegated to ClassLoader (of course). I dont like ResourceLoader also supplying newInstance(), can we remove this for analysis? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4268) Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader
[ https://issues.apache.org/jira/browse/LUCENE-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4268: -- Attachment: LUCENE-4268.patch Thanks Chris, attached new patch with test case that checks every combination of file resources and classloaders. It also fixes a bug regarding absolute paths. Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader - Key: LUCENE-4268 URL: https://issues.apache.org/jira/browse/LUCENE-4268 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 4.0, 5.0 Attachments: LUCENE-4268.patch, LUCENE-4268.patch, LUCENE-4268.patch We should rename the class and also fix some bugs: - Class/ClassLoader.getResourceAsStream() returns null when resource not found (which is a Java bug in my opinion) and does not throw IOException. SolrResourceLoader throws IOException, the Lucene example one should do the same. This prevents NPEs everywhere. Improvements: - Add no-arg CTOR that uses context class loader instead a given class. This is more what users want. Resource names must then include package name, of course. We should also provide a second implementation that allows resource names to be full filesystem paths. I think for loading the resources like custom word list, this is the most wanted implementation. Loading of classes would be delegated to ClassLoader (of course). I dont like ResourceLoader also supplying newInstance(), can we remove this for analysis? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2580) Create Components to Support Using Business Rules in Solr
[
https://issues.apache.org/jira/browse/SOLR-2580?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424342#comment-13424342
]
Erik Hatcher commented on SOLR-2580:
Grant - I'm guessing we're not getting this in for 4.0. Shall we kill the wiki
page? (or at least make it abundantly clear that it's just pie-in-the-sky for
now)
Create Components to Support Using Business Rules in Solr
-
Key: SOLR-2580
URL: https://issues.apache.org/jira/browse/SOLR-2580
Project: Solr
Issue Type: New Feature
Components: Rules
Reporter: Tomás Fernández Löbbe
Assignee: Grant Ingersoll
Fix For: 4.0
The goal is to be able to adjust the relevance of documents based on user
defined business rules.
For example, in a e-commerce site, when the user chooses the shoes
category, we may be interested in boosting products from a certain brand.
This can be expressed as a rule in the following way:
rule Boost Adidas products when searching shoes
when
$qt : QueryTool()
TermQuery(term.field==category, term.text==shoes)
then
$qt.boost({!lucene}brand:adidas);
end
The QueryTool object should be used to alter the main query in a easy way.
Even more human-like rules can be written:
rule Boost Adidas products when searching shoes
when
Query has term shoes in field product
then
Add boost query {!lucene}brand:adidas
end
These rules are written in a text file in the config directory and can be
modified at runtime. Rules will be managed using JBoss Drools:
http://www.jboss.org/drools/drools-expert.html
On a first stage, it will allow to add boost queries or change sorting fields
based on the user query, but it could be extended to allow more options.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4268) Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader
[ https://issues.apache.org/jira/browse/LUCENE-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4268: -- Attachment: LUCENE-4268.patch More test improvements. It is ready, I will commit this later! Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader - Key: LUCENE-4268 URL: https://issues.apache.org/jira/browse/LUCENE-4268 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 4.0, 5.0 Attachments: LUCENE-4268.patch, LUCENE-4268.patch, LUCENE-4268.patch, LUCENE-4268.patch We should rename the class and also fix some bugs: - Class/ClassLoader.getResourceAsStream() returns null when resource not found (which is a Java bug in my opinion) and does not throw IOException. SolrResourceLoader throws IOException, the Lucene example one should do the same. This prevents NPEs everywhere. Improvements: - Add no-arg CTOR that uses context class loader instead a given class. This is more what users want. Resource names must then include package name, of course. We should also provide a second implementation that allows resource names to be full filesystem paths. I think for loading the resources like custom word list, this is the most wanted implementation. Loading of classes would be delegated to ClassLoader (of course). I dont like ResourceLoader also supplying newInstance(), can we remove this for analysis? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Solr-trunk - Build # 1926 - Failure
Build: https://builds.apache.org/job/Solr-trunk/1926/ No tests ran. Build Log: [...truncated 37630 lines...] [...truncated 37630 lines...] [...truncated 37630 lines...] [...truncated 35394 lines...] check-forbidden-apis: validate: BUILD SUCCESSFUL Total time: 47 seconds + cd /home/hudson/hudson-slave/workspace/Solr-trunk/checkout/lucene + /home/hudson/tools/ant/supported18/bin/ant clean Buildfile: /usr/home/hudson/hudson-slave/workspace/Solr-trunk/checkout/lucene/build.xml clean: [delete] Deleting directory /usr/home/hudson/hudson-slave/workspace/Solr-trunk/checkout/lucene/build BUILD SUCCESSFUL Total time: 2 seconds + cd /home/hudson/hudson-slave/workspace/Solr-trunk/checkout/solr + ANT_OPTS='-Xmx896m -XX:+CMSClassUnloadingEnabled -XX:MaxPermSize=128M' /home/hudson/tools/ant/supported18/bin/ant -Dversion=5.0-2012-07-28_13-34-31 -Dlucene_version=5.0-2012-07-28_13-34-31 -Dsvnversion.exe=/home/hudson/tools/svn/svnversion -Dsvn.exe=/home/hudson/tools/svn/svn -Dtests.jvms=1 -Djunit.formatter=xml -Drun.clover=true -Dtests.jvms=1 -Dargs= clean-dest test generate-clover-reports Buildfile: /usr/home/hudson/hudson-slave/workspace/Solr-trunk/checkout/solr/build.xml [echo] Building solr... clean-dest: test-solr-core: [echo] Building solr-core... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ :: [ivy:configure] :: loading settings :: file = /usr/home/hudson/hudson-slave/workspace/Solr-trunk/checkout/lucene/ivy-settings.xml resolve: common.init: compile-lucene-core: jflex-uptodate-check: jflex-notice: javacc-uptodate-check: javacc-notice: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /usr/home/hudson/hudson-slave/workspace/Solr-trunk/checkout/lucene/ivy-settings.xml resolve: init: -clover.disable: -clover.setup: [echo] Code coverage with Atlassian Clover enabled. [ivy:cachepath] :: resolving dependencies :: com.cenqua.clover#clover-caller;working [ivy:cachepath] confs: [master] [ivy:cachepath] found com.cenqua.clover#clover;2.6.3 in public [ivy:cachepath] :: resolution report :: resolve 17ms :: artifacts dl 1ms - | |modules|| artifacts | | conf | number| search|dwnlded|evicted|| number|dwnlded| - | master | 1 | 0 | 0 | 0 || 1 | 0 | - [mkdir] Created dir: /usr/home/hudson/hudson-slave/workspace/Solr-trunk/checkout/lucene/build/clover/db [clover-setup] Clover Version 2.6.3, built on November 20 2009 (build-778) [clover-setup] Loaded from: /home/hudson/.ivy2/cache/com.cenqua.clover/clover/jars/clover-2.6.3.jar [clover-setup] Clover: Open Source License registered to Apache. [...truncated 2160 lines...] [...truncated 37630 lines...] [...truncated 37567 lines...] FATAL: Unable to delete script file /var/tmp/hudson7596397129283812084.sh hudson.util.IOException2: remote file operation failed: /var/tmp/hudson7596397129283812084.sh at hudson.remoting.Channel@5745854e:lucene at hudson.FilePath.act(FilePath.java:838) at hudson.FilePath.act(FilePath.java:824) at hudson.FilePath.delete(FilePath.java:1129) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:92) at hudson.tasks.CommandInterpreter.perform(CommandInterpreter.java:58) at hudson.tasks.BuildStepMonitor$1.perform(BuildStepMonitor.java:19) at hudson.model.AbstractBuild$AbstractBuildExecution.perform(AbstractBuild.java:717) at hudson.model.Build$BuildExecution.build(Build.java:199) at hudson.model.Build$BuildExecution.doRun(Build.java:160) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:499) at hudson.model.Run.execute(Run.java:1488) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: hudson.remoting.ChannelClosedException: channel is already closed at hudson.remoting.Channel.send(Channel.java:492) at hudson.remoting.Request.call(Request.java:129) at hudson.remoting.Channel.call(Channel.java:663) at hudson.FilePath.act(FilePath.java:831) ... 13 more Caused by: java.io.IOException: Unexpected termination of the channel at hudson.remoting.SynchronousCommandTransport$ReaderThread.run(SynchronousCommandTransport.java:50) Caused by: java.io.EOFException at java.io.ObjectInputStream$BlockDataInputStream.peekByte(ObjectInputStream.java:2571) at
[jira] [Commented] (LUCENE-4208) Spatial distance relevancy should use score of 1/distance
[
https://issues.apache.org/jira/browse/LUCENE-4208?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424358#comment-13424358
]
Chris Male commented on LUCENE-4208:
Having thought about this more I think the best way forward is to just emulate
free-text queries and have a {{SpatialSimilarity}} abstraction. I'm not sure
of the exact nature of the API for this but I think there are times with using
1/x is sufficient and there are probably times when a more convoluted algorithm
fits. We should allow the consumer to control what they choose.
I think the Similarity should be given the Query Shape, the matched docID and
the current SpatialOperation as a minimum. I'd like to somehow see a way to
also pass in a pre-computed distance (for Queries that compute it as part of
their matching) and possibly the matched grid hash for anything using the
PrefixTrees. We might have to have subclasses for those, or maybe a Command or
something, I'm not sure.
Other benefits:
- We immediately open up the ability to have more complex similarity scores
based on overlap percentage or anything really.
- It is plausible that a SpatialSimilarity might use a cache of indexed Shapes
to facilitate more complex algorithms. By having this abstraction we offload
the caching from the main API.
- It is also plausible that a SpatialSimilarity instance could be misused to
cache calculated distances if the consumer so wanted.
I think we should consider whether we want SpatialSimilarities to also be given
the current IndexReader (and so be able to use it in any caches or other
lookups) or whether we want them to be IR independent.
We will also need some custom Queries to actually make use of the
SpatialSimilarity. Need to think this one through a little.
Spatial distance relevancy should use score of 1/distance
-
Key: LUCENE-4208
URL: https://issues.apache.org/jira/browse/LUCENE-4208
Project: Lucene - Core
Issue Type: New Feature
Components: modules/spatial
Reporter: David Smiley
Fix For: 4.0
The SpatialStrategy.makeQuery() at the moment uses the distance as the score
(although some strategies -- TwoDoubles if I recall might not do anything
which would be a bug). The distance is a poor value to use as the score
because the score should be related to relevancy, and the distance itself is
inversely related to that. A score of 1/distance would be nice. Another
alternative is earthCircumference/2 - distance, although I like 1/distance
better. Maybe use a different constant than 1.
Credit: this is Chris Male's idea.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Reindexing after database change
Hello, I am working on a Data warehouse project and importing a huge mass of data directly to the database (MysQL). After conclude the project and roll out to production, I have discovered that one of the websites, which has to access this database, is using Lucene. Result: the data I have inserted is not being showed in this website. I have never worked with Lucena before, and I don't have access to the website source code. Is there any approach to update the Lucene index outside the program, maybe command line? (would be the whole index, once this process runs out of critical periods) Best regards, and thanks in advance. Rodrigo. -- View this message in context: http://lucene.472066.n3.nabble.com/Reindexing-after-database-change-tp3997872.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux-Java8-64 - Build # 27 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux-Java8-64/27/ 1 tests failed. REGRESSION: org.apache.solr.handler.component.SpellCheckComponentTest.testPerDictionary Error Message: mismatch: '0'!='2' @ spellcheck/suggestions/bar/startOffset Stack Trace: java.lang.RuntimeException: mismatch: '0'!='2' @ spellcheck/suggestions/bar/startOffset at __randomizedtesting.SeedInfo.seed([97860A0B3A25F391:5088FEA33249E6D9]:0) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:572) at org.apache.solr.SolrTestCaseJ4.assertJQ(SolrTestCaseJ4.java:520) at org.apache.solr.handler.component.SpellCheckComponentTest.testPerDictionary(SpellCheckComponentTest.java:102) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:474) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:818) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53) at org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551) Build Log: [...truncated 8069 lines...] [junit4:junit4] Suite: org.apache.solr.handler.component.SpellCheckComponentTest [junit4:junit4] (@BeforeClass output) [junit4:junit4] 2 0 T1503 oas.SolrTestCaseJ4.initCore initCore [junit4:junit4] 2
[jira] [Updated] (SOLR-3605) Problem with group paging (or JavaBinCodec conversion error for the request)
[ https://issues.apache.org/jira/browse/SOLR-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Serdyn du Toit updated SOLR-3605: - Attachment: TestBinaryResponseWriterError2.txt Test that catches the bug Problem with group paging (or JavaBinCodec conversion error for the request) Key: SOLR-3605 URL: https://issues.apache.org/jira/browse/SOLR-3605 Project: Solr Issue Type: Bug Components: clients - java, search Affects Versions: 3.5, 3.6 Environment: Problem first encountered in running Solr 3.5 under Ubuntu. Now upgraded to Solr 3.6 but the problem is still present. Reporter: Serdyn du Toit Labels: group, javabincodec, paging, solrj Attachments: TestBinaryResponseWriterError2.txt With Solr 3.6 the following Solr request fails: (using the example configuration) SolrQuery solrQuery = new SolrQuery(); solrQuery.setQuery(tshirt); solrQuery.setQueryType(search); solrQuery.add(GroupParams.GROUP, true); solrQuery.add(GroupParams.GROUP_FORMAT, grouped); solrQuery.add(GroupParams.GROUP_MAIN, true); solrQuery.add(GroupParams.GROUP_FIELD, manu_exact); solrQuery.setStart(30); solrQuery.setRows(30); org.apache.solr.client.solrj.SolrServerException: Error executing query at org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:95) ~[apache-solr-solrj-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:08] at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:311) ~[apache-solr-solrj-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:08] //at com.core.util.integration.solr.dao.SolrUtil.executeQuery(SolrUtil.java:204) ~[classes/:na] //at com.blapit.integration.v1.deals.restendpoints.endpoints.test.DealsByKeywordSearchEndpointFuncTest.test(DealsByKeywordSearchEndpointFuncTest.java:40) [classes/:na] at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) ~[na:1.7.0_147-icedtea] at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) ~[na:1.7.0_147-icedtea] at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) ~[na:1.7.0_147-icedtea] at java.lang.reflect.Method.invoke(Method.java:601) ~[na:1.7.0_147-icedtea] at junit.framework.TestCase.runTest(TestCase.java:168) [junit-4.10.jar:na] at junit.framework.TestCase.runBare(TestCase.java:134) [junit-4.10.jar:na] at junit.framework.TestResult$1.protect(TestResult.java:110) [junit-4.10.jar:na] at junit.framework.TestResult.runProtected(TestResult.java:128) [junit-4.10.jar:na] at junit.framework.TestResult.run(TestResult.java:113) [junit-4.10.jar:na] at junit.framework.TestCase.run(TestCase.java:124) [junit-4.10.jar:na] at junit.framework.TestSuite.runTest(TestSuite.java:243) [junit-4.10.jar:na] at junit.framework.TestSuite.run(TestSuite.java:238) [junit-4.10.jar:na] at org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83) [junit-4.10.jar:na] at org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50) [.cp/:na] at org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38) [.cp/:na] at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467) [.cp/:na] at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683) [.cp/:na] at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390) [.cp/:na] at org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197) [.cp/:na] Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to java.util.List at org.apache.solr.common.util.JavaBinCodec.readSolrDocumentList(JavaBinCodec.java:340) ~[apache-solr-solrj-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:08] at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:207) ~[apache-solr-solrj-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:08] at org.apache.solr.common.util.JavaBinCodec.readOrderedMap(JavaBinCodec.java:111) ~[apache-solr-solrj-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:08] at org.apache.solr.common.util.JavaBinCodec.readVal(JavaBinCodec.java:174) ~[apache-solr-solrj-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:08] at org.apache.solr.common.util.JavaBinCodec.unmarshal(JavaBinCodec.java:102) ~[apache-solr-solrj-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:08] at org.apache.solr.client.solrj.impl.BinaryResponseParser.processResponse(BinaryResponseParser.java:41)
[jira] [Commented] (SOLR-3605) Problem with group paging (or JavaBinCodec conversion error for the request)
[
https://issues.apache.org/jira/browse/SOLR-3605?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424377#comment-13424377
]
Serdyn du Toit commented on SOLR-3605:
--
For Solr 3.6 (not sure if this bug is present in Solr 4+)
I have added a test that catches the bug to this ticket. The error is thrown
by the JavaBinCodec but I think its because bad data is sent to it.
For my usecase the Grouping class constructs a DocSlice as follows:
org.apache.solr.search.DocSlice@c792d4[offset=10,len=-10,docs={},scores={},matches=0,maxScore=-Infinity]
When I compared this to non-grouped operations the negative 'len' variable
seemed spurious - as did the 'maxScore' value. It is this negative 'len' value
which causes the JavaBinCodec to fail.
In the Grouping class I replaced
int len = docsGathered - offset;
with
int len = docsGathered - offset;
// quick hack to fix the bug:
if (len 0)
len = 0;
I would appreciate if a Solr committer familiar with the Grouping functionality
can turn my hack into a fix and commit it.
Much appreciated
Problem with group paging (or JavaBinCodec conversion error for the request)
Key: SOLR-3605
URL: https://issues.apache.org/jira/browse/SOLR-3605
Project: Solr
Issue Type: Bug
Components: clients - java, search
Affects Versions: 3.5, 3.6
Environment: Problem first encountered in running Solr 3.5 under
Ubuntu. Now upgraded to Solr 3.6 but the problem is still present.
Reporter: Serdyn du Toit
Labels: group, javabincodec, paging, solrj
Attachments: TestBinaryResponseWriterError2.txt
With Solr 3.6 the following Solr request fails:
(using the example configuration)
SolrQuery solrQuery = new SolrQuery();
solrQuery.setQuery(tshirt);
solrQuery.setQueryType(search);
solrQuery.add(GroupParams.GROUP, true);
solrQuery.add(GroupParams.GROUP_FORMAT, grouped);
solrQuery.add(GroupParams.GROUP_MAIN, true);
solrQuery.add(GroupParams.GROUP_FIELD, manu_exact);
solrQuery.setStart(30);
solrQuery.setRows(30);
org.apache.solr.client.solrj.SolrServerException: Error executing query
at
org.apache.solr.client.solrj.request.QueryRequest.process(QueryRequest.java:95)
~[apache-solr-solrj-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:08]
at org.apache.solr.client.solrj.SolrServer.query(SolrServer.java:311)
~[apache-solr-solrj-3.6.0.jar:3.6.0 1310449 - rmuir - 2012-04-06 11:34:08]
//at
com.core.util.integration.solr.dao.SolrUtil.executeQuery(SolrUtil.java:204)
~[classes/:na]
//at
com.blapit.integration.v1.deals.restendpoints.endpoints.test.DealsByKeywordSearchEndpointFuncTest.test(DealsByKeywordSearchEndpointFuncTest.java:40)
[classes/:na]
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
~[na:1.7.0_147-icedtea]
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
~[na:1.7.0_147-icedtea]
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
~[na:1.7.0_147-icedtea]
at java.lang.reflect.Method.invoke(Method.java:601)
~[na:1.7.0_147-icedtea]
at junit.framework.TestCase.runTest(TestCase.java:168)
[junit-4.10.jar:na]
at junit.framework.TestCase.runBare(TestCase.java:134)
[junit-4.10.jar:na]
at junit.framework.TestResult$1.protect(TestResult.java:110)
[junit-4.10.jar:na]
at junit.framework.TestResult.runProtected(TestResult.java:128)
[junit-4.10.jar:na]
at junit.framework.TestResult.run(TestResult.java:113)
[junit-4.10.jar:na]
at junit.framework.TestCase.run(TestCase.java:124) [junit-4.10.jar:na]
at junit.framework.TestSuite.runTest(TestSuite.java:243)
[junit-4.10.jar:na]
at junit.framework.TestSuite.run(TestSuite.java:238) [junit-4.10.jar:na]
at
org.junit.internal.runners.JUnit38ClassRunner.run(JUnit38ClassRunner.java:83)
[junit-4.10.jar:na]
at
org.eclipse.jdt.internal.junit4.runner.JUnit4TestReference.run(JUnit4TestReference.java:50)
[.cp/:na]
at
org.eclipse.jdt.internal.junit.runner.TestExecution.run(TestExecution.java:38)
[.cp/:na]
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:467)
[.cp/:na]
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.runTests(RemoteTestRunner.java:683)
[.cp/:na]
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.run(RemoteTestRunner.java:390)
[.cp/:na]
at
org.eclipse.jdt.internal.junit.runner.RemoteTestRunner.main(RemoteTestRunner.java:197)
[.cp/:na]
Caused by: java.lang.ClassCastException: java.lang.String cannot be cast to
java.util.List
at
[jira] [Updated] (SOLR-358) Implement solr-ruby-specific response capability
[ https://issues.apache.org/jira/browse/SOLR-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-358: -- Attachment: SOLR-358.patch Patch that adds DateTime.parse around date strings when ruby.richer_types=true. This requires that one have the date module loaded (require 'date') to eval the response, but then provides dates as true DateTime objects in Ruby. Implement solr-ruby-specific response capability Key: SOLR-358 URL: https://issues.apache.org/jira/browse/SOLR-358 Project: Solr Issue Type: Improvement Components: clients - ruby - flare Reporter: Erik Hatcher Assignee: Erik Hatcher Attachments: SOLR-358.patch Implement solr-ruby-specific Ruby output, such that dates get created as real DateTime objects (wrap with DateTime.parse(...) is one option), and so that named lists maintain name and order access cleanly. This could be a formating option for wt=ruby, or a new writer type - suggestions welcome. This would make the richest way to access Solr from Ruby, with the standard Hash access unaffected and suitable for cases where using an additional library isn't desired. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4269) TestBalancedSegmentMergePolicy.setUp hang
Michael McCandless created LUCENE-4269:
--
Summary: TestBalancedSegmentMergePolicy.setUp hang
Key: LUCENE-4269
URL: https://issues.apache.org/jira/browse/LUCENE-4269
Project: Lucene - Core
Issue Type: Bug
Reporter: Michael McCandless
http://85.25.120.39/job/Lucene-trunk-Linux-Java7-64 was hung for a couple days
... stacktrace:
{noformat}
2012-07-28 13:45:03
Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.1-b03 mixed mode):
TEST-TestScope-org.apache.lucene.index.TestBalancedSegmentMergePolicy.testForceMerge-seed#[F42FFCD5FAEE14FF]
prio=10 tid=0x7f56e8371800 nid=0x106c runnable [0x7f56b213]
java.lang.Thread.State: RUNNABLE
at
org.apache.lucene.codecs.BlockTreeTermsWriter$TermsWriter$FindBlocks.freeze(BlockTreeTermsWriter.java:392)
at org.apache.lucene.util.fst.Builder.freezeTail(Builder.java:212)
at org.apache.lucene.util.fst.Builder.add(Builder.java:392)
at
org.apache.lucene.codecs.BlockTreeTermsWriter$TermsWriter.finishTerm(BlockTreeTermsWriter.java:864)
at org.apache.lucene.codecs.TermsConsumer.merge(TermsConsumer.java:167)
at org.apache.lucene.codecs.FieldsConsumer.merge(FieldsConsumer.java:65)
at
org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:323)
at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:110)
at
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3539)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3154)
at
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:36)
- locked 0xdc0fcfb8 (a
org.apache.lucene.index.SerialMergeScheduler)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1727)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1721)
at
org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:2612)
- locked 0xdc0fcfc8 (a java.lang.Object)
at
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2699)
- locked 0xdc0fcfc8 (a java.lang.Object)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2679)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2663)
at
org.apache.lucene.index.RandomIndexWriter.commit(RandomIndexWriter.java:346)
at
org.apache.lucene.index.TestBalancedSegmentMergePolicy.setUp(TestBalancedSegmentMergePolicy.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:875)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
[jira] [Commented] (LUCENE-4269) TestBalancedSegmentMergePolicy.setUp hang
[
https://issues.apache.org/jira/browse/LUCENE-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424391#comment-13424391
]
Michael McCandless commented on LUCENE-4269:
Events file:
{noformat}
[
BOOTSTRAP,
{
defaultCharset: US-ASCII,
systemProperties: {
awt.toolkit: sun.awt.X11.XToolkit,
file.encoding: US-ASCII,
file.encoding.pkg: sun.io,
file.separator: /,
java.awt.graphicsenv: sun.awt.X11GraphicsEnvironment,
java.awt.printerjob: sun.print.PSPrinterJob,
java.class.path:
/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java7-64/checkout/lucene/build/test-framework/classes/java:/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java7-64/checkout/lucene/build/core/classes/java:/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java7-64/checkout/lucene/test-framework/lib/junit-4.10.jar:/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java7-64/checkout/lucene/test-framework/lib/randomizedtesting-runner-1.6.0.jar:/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java7-64/checkout/lucene/build/misc/classes/java:/var/lib/jenkins/workspace/Lucene-trunk-Linux-Java7-64/checkout/lucene/build/misc/classes/test:/var/lib/jenkins/tools/ant/supported18/lib/ant-launcher.jar:/var/lib/jenkins/.ant/lib/apache-rat-tasks-0.8.jar:/var/lib/jenkins/.ant/lib/ivy-2.2.0.jar:/var/lib/jenkins/.ant/lib/apache-rat-0.8.jar:/var/lib/jenkins/.ant/lib/apache-rat-plugin-0.8.jar:/var/lib/jenkins/.ant/lib/apache-rat-core-0.8.jar:/var/lib/jenkins/.ant/lib/clover-2.6.3.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-apache-regexp.jar:/var/lib/jenkins/tools/ant/supported18/lib/ivy-2.2.0.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-jmf.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-apache-log4j.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-jdepend.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-swing.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-antlr.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-apache-xalan2.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-apache-resolver.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-commons-logging.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-testutil.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-apache-bcel.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-jsch.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-junit.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-commons-net.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-apache-bsf.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-junit4.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-jai.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-javamail.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-apache-oro.jar:/var/lib/jenkins/tools/ant/supported18/lib/ant-netrexx.jar:/opt/java/64/jdk1.7.0_05/lib/tools.jar:/var/lib/jenkins/.ivy2/cache/com.carrotsearch.randomizedtesting/junit4-ant/jars/junit4-ant-1.6.0.jar,
java.class.version: 51.0,
java.endorsed.dirs: /opt/java/64/jdk1.7.0_05/jre/lib/endorsed,
java.ext.dirs:
/opt/java/64/jdk1.7.0_05/jre/lib/ext:/usr/java/packages/lib/ext,
java.home: /opt/java/64/jdk1.7.0_05/jre,
java.io.tmpdir: /tmp,
java.library.path:
/usr/java/packages/lib/amd64:/usr/lib64:/lib64:/lib:/usr/lib,
java.runtime.name: Java(TM) SE Runtime Environment,
java.runtime.version: 1.7.0_05-b05,
java.specification.name: Java Platform API Specification,
java.specification.vendor: Oracle Corporation,
java.specification.version: 1.7,
java.util.logging.config.file: /dev/null,
java.vendor: Oracle Corporation,
java.vendor.url: http://java.oracle.com/;,
java.vendor.url.bug: http://bugreport.sun.com/bugreport/;,
java.version: 1.7.0_05,
java.vm.info: mixed mode,
java.vm.name: Java HotSpot(TM) 64-Bit Server VM,
java.vm.specification.name: Java Virtual Machine Specification,
java.vm.specification.vendor: Oracle Corporation,
java.vm.specification.version: 1.7,
java.vm.vendor: Oracle Corporation,
java.vm.version: 23.1-b03,
jetty.insecurerandom: 1,
jetty.testMode: 1,
junit4.memory.total: 131072000,
junit4.processors: 8,
line.separator: \n,
lucene.version: 5.0-SNAPSHOT,
os.arch: amd64,
os.name: Linux,
os.version: 3.2.0-26-generic,
path.separator: :,
solr.directoryFactory: org.apache.solr.core.MockDirectoryFactory,
sun.arch.data.model: 64,
sun.boot.class.path:
/opt/java/64/jdk1.7.0_05/jre/lib/resources.jar:/opt/java/64/jdk1.7.0_05/jre/lib/rt.jar:/opt/java/64/jdk1.7.0_05/jre/lib/sunrsasign.jar:/opt/java/64/jdk1.7.0_05/jre/lib/jsse.jar:/opt/java/64/jdk1.7.0_05/jre/lib/jce.jar:/opt/java/64/jdk1.7.0_05/jre/lib/charsets.jar:/opt/java/64/jdk1.7.0_05/jre/lib/jfr.jar:/opt/java/64/jdk1.7.0_05/jre/classes,
[jira] [Closed] (SOLR-1486) Make getting solrJS running easier.
[ https://issues.apache.org/jira/browse/SOLR-1486?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Eric Pugh closed SOLR-1486. --- Resolution: Not A Problem SolrJS is now superseded by AjaxSolr, and not part of Solr. Make getting solrJS running easier. --- Key: SOLR-1486 URL: https://issues.apache.org/jira/browse/SOLR-1486 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Eric Pugh Attachments: README, ReutersService.java.patch, build.xml.patch I am attaching a patch for simplifying starting up SolrJS. I found that the indexing process would break on a bad file, so made the indexing Java class a bit more robust. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-358) Implement solr-ruby-specific response capability
[ https://issues.apache.org/jira/browse/SOLR-358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher resolved SOLR-358. --- Resolution: Won't Fix This was a nice thought experiment, but at this point solr-ruby is mothballed and I'm not particularly interested in pushing richer types into RSolr. It's a shame that JSON, Ruby, etc are String-typed dates, but not worth the effort to battle it at this point. Implement solr-ruby-specific response capability Key: SOLR-358 URL: https://issues.apache.org/jira/browse/SOLR-358 Project: Solr Issue Type: Improvement Components: clients - ruby - flare Reporter: Erik Hatcher Assignee: Erik Hatcher Attachments: SOLR-358.patch Implement solr-ruby-specific Ruby output, such that dates get created as real DateTime objects (wrap with DateTime.parse(...) is one option), and so that named lists maintain name and order access cleanly. This could be a formating option for wt=ruby, or a new writer type - suggestions welcome. This would make the richest way to access Solr from Ruby, with the standard Hash access unaffected and suitable for cases where using an additional library isn't desired. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4269) TestBalancedSegmentMergePolicy.setUp hang
[
https://issues.apache.org/jira/browse/LUCENE-4269?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424396#comment-13424396
]
Robert Muir commented on LUCENE-4269:
-
Note also users have reported actual hangs, such as
http://www.lucidimagination.com/search/document/79dbebe26ad5c804
TestBalancedSegmentMergePolicy.setUp hang
-
Key: LUCENE-4269
URL: https://issues.apache.org/jira/browse/LUCENE-4269
Project: Lucene - Core
Issue Type: Bug
Reporter: Michael McCandless
http://85.25.120.39/job/Lucene-trunk-Linux-Java7-64 was hung for a couple
days ... stacktrace:
{noformat}
2012-07-28 13:45:03
Full thread dump Java HotSpot(TM) 64-Bit Server VM (23.1-b03 mixed mode):
TEST-TestScope-org.apache.lucene.index.TestBalancedSegmentMergePolicy.testForceMerge-seed#[F42FFCD5FAEE14FF]
prio=10 tid=0x7f56e8371800 nid=0x106c runnable [0x7f56b213]
java.lang.Thread.State: RUNNABLE
at
org.apache.lucene.codecs.BlockTreeTermsWriter$TermsWriter$FindBlocks.freeze(BlockTreeTermsWriter.java:392)
at org.apache.lucene.util.fst.Builder.freezeTail(Builder.java:212)
at org.apache.lucene.util.fst.Builder.add(Builder.java:392)
at
org.apache.lucene.codecs.BlockTreeTermsWriter$TermsWriter.finishTerm(BlockTreeTermsWriter.java:864)
at org.apache.lucene.codecs.TermsConsumer.merge(TermsConsumer.java:167)
at org.apache.lucene.codecs.FieldsConsumer.merge(FieldsConsumer.java:65)
at
org.apache.lucene.index.SegmentMerger.mergeTerms(SegmentMerger.java:323)
at org.apache.lucene.index.SegmentMerger.merge(SegmentMerger.java:110)
at
org.apache.lucene.index.IndexWriter.mergeMiddle(IndexWriter.java:3539)
at org.apache.lucene.index.IndexWriter.merge(IndexWriter.java:3154)
at
org.apache.lucene.index.SerialMergeScheduler.merge(SerialMergeScheduler.java:36)
- locked 0xdc0fcfb8 (a
org.apache.lucene.index.SerialMergeScheduler)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1727)
at org.apache.lucene.index.IndexWriter.maybeMerge(IndexWriter.java:1721)
at
org.apache.lucene.index.IndexWriter.prepareCommit(IndexWriter.java:2612)
- locked 0xdc0fcfc8 (a java.lang.Object)
at
org.apache.lucene.index.IndexWriter.commitInternal(IndexWriter.java:2699)
- locked 0xdc0fcfc8 (a java.lang.Object)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2679)
at org.apache.lucene.index.IndexWriter.commit(IndexWriter.java:2663)
at
org.apache.lucene.index.RandomIndexWriter.commit(RandomIndexWriter.java:346)
at
org.apache.lucene.index.TestBalancedSegmentMergePolicy.setUp(TestBalancedSegmentMergePolicy.java:55)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:601)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:875)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697)
at
[jira] [Resolved] (LUCENE-4268) Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader
[ https://issues.apache.org/jira/browse/LUCENE-4268?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-4268. --- Resolution: Fixed Committed trunk revision: 1366748 Committed 4.x revision: 1366749 Rename ResourceAsStreamReasourceLoader to ClasspathResourceLoader, supply simple FilesystemResourceLoader - Key: LUCENE-4268 URL: https://issues.apache.org/jira/browse/LUCENE-4268 Project: Lucene - Core Issue Type: Bug Components: modules/analysis Reporter: Uwe Schindler Assignee: Uwe Schindler Fix For: 4.0, 5.0 Attachments: LUCENE-4268.patch, LUCENE-4268.patch, LUCENE-4268.patch, LUCENE-4268.patch We should rename the class and also fix some bugs: - Class/ClassLoader.getResourceAsStream() returns null when resource not found (which is a Java bug in my opinion) and does not throw IOException. SolrResourceLoader throws IOException, the Lucene example one should do the same. This prevents NPEs everywhere. Improvements: - Add no-arg CTOR that uses context class loader instead a given class. This is more what users want. Resource names must then include package name, of course. We should also provide a second implementation that allows resource names to be full filesystem paths. I think for loading the resources like custom word list, this is the most wanted implementation. Loading of classes would be delegated to ClassLoader (of course). I dont like ResourceLoader also supplying newInstance(), can we remove this for analysis? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux-Java7-64 - Build # 569 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux-Java7-64/569/ 1 tests failed. FAILED: org.apache.lucene.analysis.util.TestFilesystemResourceLoader.testBaseDir Error Message: Resource not found: ./fsResourceLoaderBase7518375200tmp/template.txt Stack Trace: java.io.IOException: Resource not found: ./fsResourceLoaderBase7518375200tmp/template.txt at __randomizedtesting.SeedInfo.seed([9072A707A613233A:AA5B118DD0352D02]:0) at org.apache.lucene.analysis.util.ClasspathResourceLoader.openResource(ClasspathResourceLoader.java:67) at org.apache.lucene.analysis.util.FilesystemResourceLoader.openResource(FilesystemResourceLoader.java:86) at org.apache.lucene.analysis.util.TestFilesystemResourceLoader.testBaseDir(TestFilesystemResourceLoader.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:818) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53) at org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551) Build Log: [...truncated 4427 lines...] [junit4:junit4] Suite: org.apache.lucene.analysis.util.TestFilesystemResourceLoader [junit4:junit4] ERROR 0.05s J0 | TestFilesystemResourceLoader.testBaseDir [junit4:junit4] Throwable #1: java.io.IOException: Resource not found: ./fsResourceLoaderBase7518375200tmp/template.txt [junit4:junit4]at __randomizedtesting.SeedInfo.seed([9072A707A613233A:AA5B118DD0352D02]:0)
[JENKINS] Lucene-Solr-trunk-Linux-Java7-64 - Build # 737 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java7-64/737/ 1 tests failed. FAILED: org.apache.lucene.analysis.util.TestFilesystemResourceLoader.testBaseDir Error Message: Resource not found: ./fsResourceLoaderBase4682246822tmp/template.txt Stack Trace: java.io.IOException: Resource not found: ./fsResourceLoaderBase4682246822tmp/template.txt at __randomizedtesting.SeedInfo.seed([AD5802E6257518AC:9771B46C53531694]:0) at org.apache.lucene.analysis.util.ClasspathResourceLoader.openResource(ClasspathResourceLoader.java:67) at org.apache.lucene.analysis.util.FilesystemResourceLoader.openResource(FilesystemResourceLoader.java:86) at org.apache.lucene.analysis.util.TestFilesystemResourceLoader.testBaseDir(TestFilesystemResourceLoader.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:818) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53) at org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551) Build Log: [...truncated 3701 lines...] [junit4:junit4] Suite: org.apache.lucene.analysis.util.TestFilesystemResourceLoader [junit4:junit4] ERROR 0.08s J1 | TestFilesystemResourceLoader.testBaseDir [junit4:junit4] Throwable #1: java.io.IOException: Resource not found: ./fsResourceLoaderBase4682246822tmp/template.txt [junit4:junit4]at __randomizedtesting.SeedInfo.seed([AD5802E6257518AC:9771B46C53531694]:0)
[JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2982 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2982/ 1 tests failed. FAILED: org.apache.lucene.analysis.util.TestFilesystemResourceLoader.testBaseDir Error Message: Resource not found: ./fsResourceLoaderBase2772427724tmp/template.txt Stack Trace: java.io.IOException: Resource not found: ./fsResourceLoaderBase2772427724tmp/template.txt at __randomizedtesting.SeedInfo.seed([E2DA674FCFE4EDB2:D8F3D1C5B9C2E38A]:0) at org.apache.lucene.analysis.util.ClasspathResourceLoader.openResource(ClasspathResourceLoader.java:67) at org.apache.lucene.analysis.util.FilesystemResourceLoader.openResource(FilesystemResourceLoader.java:86) at org.apache.lucene.analysis.util.TestFilesystemResourceLoader.testBaseDir(TestFilesystemResourceLoader.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:818) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53) at org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551) Build Log: [...truncated 4927 lines...] compile-lucene-core: init: -clover.disable: -clover.setup: clover: common.compile-core: compile-core: compile-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk-java7/checkout/lucene/ivy-settings.xml resolve: init: compile-lucene-core: compile-core:
RE: [JENKINS] Lucene-Solr-trunk-Linux-Java7-64 - Build # 737 - Failure!
Sorry, fixed this. The problem in test was that path was not absolute in this configuration. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Policeman Jenkins Server [mailto:jenk...@sd-datasolutions.de] Sent: Saturday, July 28, 2012 9:56 PM To: dev@lucene.apache.org; u...@thetaphi.de Subject: [JENKINS] Lucene-Solr-trunk-Linux-Java7-64 - Build # 737 - Failure! Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java7- 64/737/ 1 tests failed. FAILED: org.apache.lucene.analysis.util.TestFilesystemResourceLoader.testBaseDir Error Message: Resource not found: ./fsResourceLoaderBase4682246822tmp/template.txt Stack Trace: java.io.IOException: Resource not found: ./fsResourceLoaderBase4682246822tmp/template.txt at __randomizedtesting.SeedInfo.seed([AD5802E6257518AC:9771B46C53531694]: 0) at org.apache.lucene.analysis.util.ClasspathResourceLoader.openResource(Classp athResourceLoader.java:67) at org.apache.lucene.analysis.util.FilesystemResourceLoader.openResource(Filesy stemResourceLoader.java:86) at org.apache.lucene.analysis.util.TestFilesystemResourceLoader.testBaseDir(Test FilesystemResourceLoader.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java: 57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorI mpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRu nner.java:1995) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(Random izedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(Randomiz edRunner.java:818) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(Randomiz edRunner.java:877) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(Randomiz edRunner.java:891) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSet upTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCach eSanity.java:32) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfte rRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.ev aluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRule ReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThrea dAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgn oreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.ja va:48) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(Rando mizedRunner.java:825) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(Randomiz edRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(Randomized Runner.java:671) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(Randomiz edRunner.java:697) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(Randomiz edRunner.java:736) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(Randomiz edRunner.java:747) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfte rRule.java:45) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRule ReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClass Name.java:38) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.ev aluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRule NoInstanceHooksOverrides.java:53) at org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleN oStaticHooksShadowing.java:52) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertio nsRequired.java:36) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.ja va:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgn oreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTest Suites.java:55) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(Randomized Runner.java:605) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(Randomiz edRunner.java:132) at
[JENKINS] Lucene-Solr-trunk-Linux-Java8-64 - Build # 32 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux-Java8-64/32/ 1 tests failed. FAILED: org.apache.lucene.analysis.util.TestFilesystemResourceLoader.testBaseDir Error Message: Resource not found: ./fsResourceLoaderBase5094650948tmp/template.txt Stack Trace: java.io.IOException: Resource not found: ./fsResourceLoaderBase5094650948tmp/template.txt at __randomizedtesting.SeedInfo.seed([BAAD1496E9124DE5:8084A21C9F3443DD]:0) at org.apache.lucene.analysis.util.ClasspathResourceLoader.openResource(ClasspathResourceLoader.java:67) at org.apache.lucene.analysis.util.FilesystemResourceLoader.openResource(FilesystemResourceLoader.java:86) at org.apache.lucene.analysis.util.TestFilesystemResourceLoader.testBaseDir(TestFilesystemResourceLoader.java:78) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:474) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:818) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53) at org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551) Build Log: [...truncated 4323 lines...] [junit4:junit4] Suite: org.apache.lucene.analysis.util.TestFilesystemResourceLoader [junit4:junit4] ERROR 0.05s J0 | TestFilesystemResourceLoader.testBaseDir [junit4:junit4] Throwable #1: java.io.IOException: Resource not found: ./fsResourceLoaderBase5094650948tmp/template.txt [junit4:junit4]at __randomizedtesting.SeedInfo.seed([BAAD1496E9124DE5:8084A21C9F3443DD]:0)
[jira] [Commented] (LUCENE-4262) add ivy sync=true, consolidate licensing, disallow conflicting dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424411#comment-13424411 ] Dawid Weiss commented on LUCENE-4262: - bq. Sha1 checker needs to also be fixed (or is it in the license checker?). Hi. Don't know what you actually did - trying to dig myself out from a big pile of e-mail - but the lookup of sha1 files was initially written using mappers so it should be possible to modify these mappers only (ant level), without touching the code? add ivy sync=true, consolidate licensing, disallow conflicting dependencies --- Key: LUCENE-4262 URL: https://issues.apache.org/jira/browse/LUCENE-4262 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Fix For: 4.0, 5.0 Attachments: LUCENE-4262.patch, LUCENE-4262.patch, LUCENE-4262.patch From a discussion on IRC: * Hoss had the typical clean-jars problem * I mentioned we should instead use the ivy option of sync=true, which is just like retrieve except nukes any stuff (e.g. old jars) that shouldn't be there. * the problem with this is it would also nuke the .sha1 and licensing stuff (its easy to try and see). So the idea came about we could just have a licenses/ folder for each product (lucene, solr) and this has the .sha1's and licensing stuff. Steve asked what if different modules depended on different versions of the same jar: this is bogus and we should just disallow it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-4.x - Build # 354 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-4.x/354/ 1 tests failed. FAILED: org.apache.lucene.analysis.util.TestFilesystemResourceLoader.testBaseDir Error Message: Resource not found: ./fsResourceLoaderBase3961439632tmp/template.txt Stack Trace: java.io.IOException: Resource not found: ./fsResourceLoaderBase3961439632tmp/template.txt at __randomizedtesting.SeedInfo.seed([339C78F70C80AC8F:9B5CE7D7AA6A2B7]:0) at org.apache.lucene.analysis.util.ClasspathResourceLoader.openResource(ClasspathResourceLoader.java:67) at org.apache.lucene.analysis.util.FilesystemResourceLoader.openResource(FilesystemResourceLoader.java:86) at org.apache.lucene.analysis.util.TestFilesystemResourceLoader.testBaseDir(TestFilesystemResourceLoader.java:77) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:818) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53) at org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551) Build Log: [...truncated 4805 lines...] [junit4:junit4] Suite: org.apache.lucene.analysis.payloads.TokenOffsetPayloadTokenFilterTest [junit4:junit4] Completed on J0 in 0.01s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.analysis.ar.TestArabicLetterTokenizer [junit4:junit4] Completed on J1 in 0.01s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.analysis.charfilter.TestMappingCharFilterFactory
[jira] [Commented] (LUCENE-4262) add ivy sync=true, consolidate licensing, disallow conflicting dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424413#comment-13424413 ] Robert Muir commented on LUCENE-4262: - The code needed to be touched. it was mucking completely with absolute paths. add ivy sync=true, consolidate licensing, disallow conflicting dependencies --- Key: LUCENE-4262 URL: https://issues.apache.org/jira/browse/LUCENE-4262 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Fix For: 4.0, 5.0 Attachments: LUCENE-4262.patch, LUCENE-4262.patch, LUCENE-4262.patch From a discussion on IRC: * Hoss had the typical clean-jars problem * I mentioned we should instead use the ivy option of sync=true, which is just like retrieve except nukes any stuff (e.g. old jars) that shouldn't be there. * the problem with this is it would also nuke the .sha1 and licensing stuff (its easy to try and see). So the idea came about we could just have a licenses/ folder for each product (lucene, solr) and this has the .sha1's and licensing stuff. Steve asked what if different modules depended on different versions of the same jar: this is bogus and we should just disallow it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4252) Detect/Fail tests when they leak RAM in static fields
[
https://issues.apache.org/jira/browse/LUCENE-4252?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424414#comment-13424414
]
Dawid Weiss commented on LUCENE-4252:
-
Yep, looks good to me and makes sense. When I was thinking about static
initializers I had in mind twisted scenarios like:
{code}
static {
KlassB.staticField = new byte [gazillion];
}
{code}
but this will be nearly impossible to detect given that you can fan out from a
static initializer to other classes etc. Doesn't make sense to try to make it
super complex.
What we could do though is to make it not only a lint rule but also an
additional cleanup rule, similar to system property invariant guard and
cleanup. We could then add this automatic static field cleanup (on the suite
class) to the set of class rules on LuceneTestCase. Perhaps it'd make it
cleaner compared to manual cleanups done in @AfterClass or similar hooks?
Detect/Fail tests when they leak RAM in static fields
-
Key: LUCENE-4252
URL: https://issues.apache.org/jira/browse/LUCENE-4252
Project: Lucene - Core
Issue Type: Test
Components: general/test
Reporter: Robert Muir
Assignee: Dawid Weiss
Attachments: LUCENE-4252.patch, LUCENE-4252.patch
We run our junit tests without firing up a JVM each time.
But some tests initialize lots of stuff in @BeforeClass and don't properly
null it out in an @AfterClass, which can cause a subsequent test in the same
JVM to OOM, which is difficult to debug.
Inspiration for this was me committing Mike's cool TestPostingsFormat, which
forgot to do this: then we were seeing OOMs in several jenkins runs.
We should try to detect these leaks in LuceneTestCase with RAMUsageEstimator
and fail the test.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4262) add ivy sync=true, consolidate licensing, disallow conflicting dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4262?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424415#comment-13424415 ] Dawid Weiss commented on LUCENE-4262: - Ah, now I recall -- the tool I wrote was to lookup license/notice files and I did use mapper elements exactly for the purpose of potentially putting those files somewhere else. sha checker could be probably rewritten to use the same strategy although this is of very low priority if it works now I guess. add ivy sync=true, consolidate licensing, disallow conflicting dependencies --- Key: LUCENE-4262 URL: https://issues.apache.org/jira/browse/LUCENE-4262 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Fix For: 4.0, 5.0 Attachments: LUCENE-4262.patch, LUCENE-4262.patch, LUCENE-4262.patch From a discussion on IRC: * Hoss had the typical clean-jars problem * I mentioned we should instead use the ivy option of sync=true, which is just like retrieve except nukes any stuff (e.g. old jars) that shouldn't be there. * the problem with this is it would also nuke the .sha1 and licensing stuff (its easy to try and see). So the idea came about we could just have a licenses/ folder for each product (lucene, solr) and this has the .sha1's and licensing stuff. Steve asked what if different modules depended on different versions of the same jar: this is bogus and we should just disallow it! -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-4.x - Build # 355 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-4.x/355/ 1 tests failed. FAILED: org.apache.solr.cloud.RecoveryZkTest.testDistribSearch Error Message: expected:2121 but was:2373 Stack Trace: java.lang.AssertionError: expected:2121 but was:2373 at __randomizedtesting.SeedInfo.seed([382376ABDC841630:B9C5F8B3ABDB760C]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.junit.Assert.assertEquals(Assert.java:456) at org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:107) at org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:679) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:818) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:877) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53) at org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551) Build Log: [...truncated 34627 lines...] [junit4:junit4] 2at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
[jira] [Updated] (SOLR-3648) The /browse Solritas GUI does not work under SolrCloud - 500 error
[ https://issues.apache.org/jira/browse/SOLR-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-3648: --- Attachment: SOLR-3648.patch Adapted Jan's work with some tweaks. Hard-coded velocity/ in the custom resource loader (which is what gets used in SolrCloud mode). Kept file resource loader in the mix when not in SolrCloud mode. All is working now, so I'll commit and iterate on anything else remaining here. The /browse Solritas GUI does not work under SolrCloud - 500 error Key: SOLR-3648 URL: https://issues.apache.org/jira/browse/SOLR-3648 Project: Solr Issue Type: Bug Components: SearchComponents - other Affects Versions: 4.0-ALPHA Environment: RHEL 5.4, SolrCloud Reporter: Nick Cotton Assignee: Jan Høydahl Priority: Blocker Labels: patch Fix For: 4.0, 5.0 Attachments: SOLR-3648.patch, SOLR-3648.patch When run in a SolrCloud configuration the Velocity searchHandler responds to a /browse request with an HTTP error 500 and a stack trace indicating org.apache.solr.common.cloud.ZooKeeperException: ZkSolrResourceLoader does not support getConfigDir() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3648) The /browse Solritas GUI does not work under SolrCloud - 500 error
[ https://issues.apache.org/jira/browse/SOLR-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424446#comment-13424446 ] Erik Hatcher commented on SOLR-3648: Committed my patch to r1366775 (4_x) and r1366776 (trunk). The /browse Solritas GUI does not work under SolrCloud - 500 error Key: SOLR-3648 URL: https://issues.apache.org/jira/browse/SOLR-3648 Project: Solr Issue Type: Bug Components: SearchComponents - other Affects Versions: 4.0-ALPHA Environment: RHEL 5.4, SolrCloud Reporter: Nick Cotton Assignee: Jan Høydahl Priority: Blocker Labels: patch Fix For: 4.0, 5.0 Attachments: SOLR-3648.patch, SOLR-3648.patch When run in a SolrCloud configuration the Velocity searchHandler responds to a /browse request with an HTTP error 500 and a stack trace indicating org.apache.solr.common.cloud.ZooKeeperException: ZkSolrResourceLoader does not support getConfigDir() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3648) The /browse Solritas GUI does not work under SolrCloud - 500 error
[ https://issues.apache.org/jira/browse/SOLR-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424448#comment-13424448 ] Erik Hatcher commented on SOLR-3648: TODO: update VelocityResponseWriter wiki (it needs a cleanup anyway) with pertinent details. What else do you think should be done here, Jan? The one thing I didn't incorporate from your patch was the path parameter to the SolrVelocityResourceLoader (but rather hardcoded it), mainly for simplicity. I don't think that multiple path's capability should be done that way here. Either your way or my way here is a change in how it was done before by requiring it look in a velocity/ subdirectory. I doubt anyone has used it the way I was intending it to be used, so not a big deal to break it I don't think. My thinking with that, thankfully quite useful in SolrCloud mode resource loader, was that plugins/contrib modules could ship their own Velocity templates in their JAR files. Anyone using it that way will now have to put the templates in a velocity/ subdirectory inside the JAR. The /browse Solritas GUI does not work under SolrCloud - 500 error Key: SOLR-3648 URL: https://issues.apache.org/jira/browse/SOLR-3648 Project: Solr Issue Type: Bug Components: SearchComponents - other Affects Versions: 4.0-ALPHA Environment: RHEL 5.4, SolrCloud Reporter: Nick Cotton Assignee: Jan Høydahl Priority: Blocker Labels: patch Fix For: 4.0, 5.0 Attachments: SOLR-3648.patch, SOLR-3648.patch When run in a SolrCloud configuration the Velocity searchHandler responds to a /browse request with an HTTP error 500 and a stack trace indicating org.apache.solr.common.cloud.ZooKeeperException: ZkSolrResourceLoader does not support getConfigDir() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3648) The /browse Solritas GUI does not work under SolrCloud - 500 error
[ https://issues.apache.org/jira/browse/SOLR-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher resolved SOLR-3648. Resolution: Fixed Assignee: Erik Hatcher (was: Jan Høydahl) The /browse Solritas GUI does not work under SolrCloud - 500 error Key: SOLR-3648 URL: https://issues.apache.org/jira/browse/SOLR-3648 Project: Solr Issue Type: Bug Components: SearchComponents - other Affects Versions: 4.0-ALPHA Environment: RHEL 5.4, SolrCloud Reporter: Nick Cotton Assignee: Erik Hatcher Priority: Blocker Labels: patch Fix For: 4.0, 5.0 Attachments: SOLR-3648.patch, SOLR-3648.patch When run in a SolrCloud configuration the Velocity searchHandler responds to a /browse request with an HTTP error 500 and a stack trace indicating org.apache.solr.common.cloud.ZooKeeperException: ZkSolrResourceLoader does not support getConfigDir() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3687) Implement tests that exercise and assert that the example features work properly
Erik Hatcher created SOLR-3687: -- Summary: Implement tests that exercise and assert that the example features work properly Key: SOLR-3687 URL: https://issues.apache.org/jira/browse/SOLR-3687 Project: Solr Issue Type: Task Reporter: Erik Hatcher Fix For: 4.0, 5.0 The example configuration that Solr ships with wires in a number of contrib components and has other bells and whistles like the /browse search view. Tests should be created that assert at least the basics, such as all the steps of our official tutorial and the /browse view, all work as expected exactly as all integrated under example/ (or whatever we refactor it to as has been discussed). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3292) /browse example fails to load on 3x: no field name specified in query and no default specified via 'df' param
[
https://issues.apache.org/jira/browse/SOLR-3292?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erik Hatcher resolved SOLR-3292.
Resolution: Fixed
bq. Why was this not caught by any tests? Should we add one?
Jan - I have opened a separate issue for that so we can close this one for 4x:
SOLR-3687
/browse example fails to load on 3x: no field name specified in query and no
default specified via 'df' param
---
Key: SOLR-3292
URL: https://issues.apache.org/jira/browse/SOLR-3292
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Erik Hatcher
Priority: Blocker
Fix For: 4.0, 5.0, 3.6
1) java -jar start.jar using solr example on 3x branch circa r1306629
2) load http://localhost:8983/solr/browse
3) browser error: 400 no field name specified in query and no default
specified via 'df' param
4) error in logs...
{noformat}
INFO: [] webapp=/solr path=/browse params={} hits=0 status=400 QTime=3
Mar 28, 2012 4:05:59 PM org.apache.solr.common.SolrException log
SEVERE: org.apache.solr.common.SolrException: no field name specified in
query and no default specified via 'df' param
at
org.apache.solr.search.SolrQueryParser.checkNullField(SolrQueryParser.java:158)
at
org.apache.solr.search.SolrQueryParser.getFieldQuery(SolrQueryParser.java:174)
at org.apache.lucene.queryParser.QueryParser.Term(QueryParser.java:1429)
at
org.apache.lucene.queryParser.QueryParser.Clause(QueryParser.java:1317)
at
org.apache.lucene.queryParser.QueryParser.Query(QueryParser.java:1245)
at
org.apache.lucene.queryParser.QueryParser.TopLevelQuery(QueryParser.java:1234)
at org.apache.lucene.queryParser.QueryParser.parse(QueryParser.java:206)
at
org.apache.solr.search.LuceneQParser.parse(LuceneQParserPlugin.java:79)
at org.apache.solr.search.QParser.getQuery(QParser.java:143)
at
org.apache.solr.request.SimpleFacets.getFacetQueryCounts(SimpleFacets.java:233)
at
org.apache.solr.request.SimpleFacets.getFacetCounts(SimpleFacets.java:194)
at
org.apache.solr.handler.component.FacetComponent.process(FacetComponent.java:72)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:186)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1376)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3633) web UI reports an error if CoreAdminHandler says there are no SolrCores
[ https://issues.apache.org/jira/browse/SOLR-3633?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erik Hatcher updated SOLR-3633: --- Summary: web UI reports an error if CoreAdminHandler says there are no SolrCores (was: web UI reports and error if CoreAdminHandler says there are no SolrCores) web UI reports an error if CoreAdminHandler says there are no SolrCores --- Key: SOLR-3633 URL: https://issues.apache.org/jira/browse/SOLR-3633 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-ALPHA Reporter: Hoss Man Assignee: Stefan Matheis (steffkes) Fix For: 4.0 Attachments: SOLR-3633.patch Spun off from SOLR-3591... * having no SolrCores is a valid situation * independent of what may happen in SOLR-3591, the web UI should cleanly deal with there being no SolrCores, and just hide/grey out any tabs that can't be supported w/o at least one core * even if there are no SolrCores the core admin features (ie: creating a new core) should be accessible in the UI -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4109) BooleanQueries are not parsed correctly with the flexible query parser
[
https://issues.apache.org/jira/browse/LUCENE-4109?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Karsten R. updated LUCENE-4109:
---
Attachment: LUCENE-4109_trunk_rev1366771.patch
Patch against http://svn.apache.org/repos/asf/lucene/dev/trunk (rev1366771)
The patch adds the processor BooleanQuery2ModifierNodeProcessor and a
test-class TestStandardQP which extends QueryParserTestBase.
There is also a new interface CommonQueryParserConfiguration to configure
flexible and classic parser in QueryParserTestBase.
In TestStandardQP some tests from QueryParserTestBase are hidden by a
do-nothing overriding method.
The patch passes all tests from /lucene/queryparser/src. It passes because some
tests are changed (without changing any meaning). In particular
TestMultiFieldQPHelper is changed.
Still [\\* TO \*\] is parsed as [\\* TO *] and not as [\\* TO \\*].
If this patch is OK I will provide a Version 3.6.X patch.
BooleanQueries are not parsed correctly with the flexible query parser
--
Key: LUCENE-4109
URL: https://issues.apache.org/jira/browse/LUCENE-4109
Project: Lucene - Core
Issue Type: Bug
Components: modules/queryparser
Affects Versions: 3.5, 3.6
Reporter: Daniel Truemper
Assignee: Robert Muir
Fix For: 4.0
Attachments: LUCENE-4109.patch, LUCENE-4109.patch,
LUCENE-4109_trunk_rev1366771.patch, test-patch.txt
Hi,
I just found another bug in the flexible query parser (together with Robert
Muir, yay!).
The following query string works in the standard query parser:
{noformat}
(field:[1 TO *] AND field:[* TO 2]) AND field2:z
{noformat}
yields
{noformat}
+(+field:[1 TO *] +field:[* TO 2]) +field2:z
{noformat}
The flexible query parser though yields:
{noformat}
+(field:[1 TO *] field:[* TO 2]) +field2:z
{noformat}
Test patch is attached (from Robert actually).
I don't know if it affects earlier versions than 3.5.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3648) The /browse Solritas GUI does not work under SolrCloud - 500 error
[ https://issues.apache.org/jira/browse/SOLR-3648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424457#comment-13424457 ] Jan Høydahl commented on SOLR-3648: --- I'm cool with that, thanks for finalizing! The /browse Solritas GUI does not work under SolrCloud - 500 error Key: SOLR-3648 URL: https://issues.apache.org/jira/browse/SOLR-3648 Project: Solr Issue Type: Bug Components: SearchComponents - other Affects Versions: 4.0-ALPHA Environment: RHEL 5.4, SolrCloud Reporter: Nick Cotton Assignee: Erik Hatcher Priority: Blocker Labels: patch Fix For: 4.0, 5.0 Attachments: SOLR-3648.patch, SOLR-3648.patch When run in a SolrCloud configuration the Velocity searchHandler responds to a /browse request with an HTTP error 500 and a stack trace indicating org.apache.solr.common.cloud.ZooKeeperException: ZkSolrResourceLoader does not support getConfigDir() -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-4.x - Build # 356 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-4.x/356/
1 tests failed.
FAILED: org.apache.solr.cloud.RecoveryZkTest.testDistribSearch
Error Message:
expected:2205 but was:2204
Stack Trace:
java.lang.AssertionError: expected:2205 but was:2204
at
__randomizedtesting.SeedInfo.seed([CE38F241A3874F19:4FDE7C59D4D82F25]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:107)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:679)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:818)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:877)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)
Build Log:
[...truncated 34727 lines...]
[junit4:junit4] 2 41587 T1494 C91 P11540 /update {wt=javabinversion=2}
{add=[12101 (1408781649282334720)]} 0 0
[jira] [Commented] (SOLR-3687) Implement tests that exercise and assert that the example features work properly
[ https://issues.apache.org/jira/browse/SOLR-3687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13424460#comment-13424460 ] Jan Høydahl commented on SOLR-3687: --- +1 This would also catch lib classpath mismatch in solrconfig etc Implement tests that exercise and assert that the example features work properly Key: SOLR-3687 URL: https://issues.apache.org/jira/browse/SOLR-3687 Project: Solr Issue Type: Task Reporter: Erik Hatcher Fix For: 4.0, 5.0 The example configuration that Solr ships with wires in a number of contrib components and has other bells and whistles like the /browse search view. Tests should be created that assert at least the basics, such as all the steps of our official tutorial and the /browse view, all work as expected exactly as all integrated under example/ (or whatever we refactor it to as has been discussed). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-4.x - Build # 357 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-4.x/357/
1 tests failed.
FAILED: org.apache.solr.cloud.RecoveryZkTest.testDistribSearch
Error Message:
expected:1690 but was:1691
Stack Trace:
java.lang.AssertionError: expected:1690 but was:1691
at
__randomizedtesting.SeedInfo.seed([590647FDF02F84C:8476EA67A85D9870]:0)
at org.junit.Assert.fail(Assert.java:93)
at org.junit.Assert.failNotEquals(Assert.java:647)
at org.junit.Assert.assertEquals(Assert.java:128)
at org.junit.Assert.assertEquals(Assert.java:472)
at org.junit.Assert.assertEquals(Assert.java:456)
at org.apache.solr.cloud.RecoveryZkTest.doTest(RecoveryZkTest.java:107)
at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:679)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
at java.lang.reflect.Method.invoke(Method.java:616)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1995)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$1100(RandomizedRunner.java:132)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:818)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:877)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:891)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:32)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:825)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$700(RandomizedRunner.java:132)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:671)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:697)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:736)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:747)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleReportUncaughtExceptions$1.evaluate(TestRuleReportUncaughtExceptions.java:68)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:38)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleNoInstanceHooksOverrides$1.evaluate(TestRuleNoInstanceHooksOverrides.java:53)
at
org.apache.lucene.util.TestRuleNoStaticHooksShadowing$1.evaluate(TestRuleNoStaticHooksShadowing.java:52)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:36)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:605)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:132)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:551)
Build Log:
[...truncated 27953 lines...]
[junit4:junit4] 2 35406 T1828 C117 P61699 /update {wt=javabinversion=2}
{add=[1601 (1408790510944911360)]} 0 3
[JENKINS] Lucene-trunk - Build # 2007 - Failure
Build: https://builds.apache.org/job/Lucene-trunk/2007/ 1 tests failed. REGRESSION: org.apache.lucene.util.TestMaxFailuresRule.testMaxFailures Error Message: Stack Trace: java.lang.AssertionError at org.junit.Assert.fail(Assert.java:92) at org.junit.Assert.assertTrue(Assert.java:43) at org.junit.Assert.assertTrue(Assert.java:54) at org.apache.lucene.util.TestMaxFailuresRule.testMaxFailures(TestMaxFailuresRule.java:79) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.junit.runners.model.FrameworkMethod$1.runReflectiveCall(FrameworkMethod.java:45) at org.junit.internal.runners.model.ReflectiveCallable.run(ReflectiveCallable.java:15) at org.junit.runners.model.FrameworkMethod.invokeExplosively(FrameworkMethod.java:42) at org.junit.internal.runners.statements.InvokeMethod.evaluate(InvokeMethod.java:20) at org.junit.internal.runners.statements.RunBefores.evaluate(RunBefores.java:28) at org.junit.internal.runners.statements.RunAfters.evaluate(RunAfters.java:30) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.junit.rules.RunRules.evaluate(RunRules.java:18) at org.junit.runners.ParentRunner.runLeaf(ParentRunner.java:263) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:68) at org.junit.runners.BlockJUnit4ClassRunner.runChild(BlockJUnit4ClassRunner.java:47) at org.junit.runners.ParentRunner$3.run(ParentRunner.java:231) at org.junit.runners.ParentRunner$1.schedule(ParentRunner.java:60) at org.junit.runners.ParentRunner.runChildren(ParentRunner.java:229) at org.junit.runners.ParentRunner.access$000(ParentRunner.java:50) at org.junit.runners.ParentRunner$2.evaluate(ParentRunner.java:222) at org.junit.runners.ParentRunner.run(ParentRunner.java:300) at com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.execute(SlaveMain.java:153) at com.carrotsearch.ant.tasks.junit4.slave.SlaveMain.main(SlaveMain.java:246) at com.carrotsearch.ant.tasks.junit4.slave.SlaveMainSafe.main(SlaveMainSafe.java:12) Build Log: [...truncated 18367 lines...] [junit4:junit4] Suite: org.apache.lucene.util.junitcompat.TestSeedFromUncaught [junit4:junit4] Completed on J0 in 0.03s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestSegmentTermEnum [junit4:junit4] Completed on J1 in 0.09s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spans.TestSpansAdvanced [junit4:junit4] Completed on J0 in 0.03s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestConstantScoreQuery [junit4:junit4] Completed on J1 in 0.02s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestPhrasePrefixQuery [junit4:junit4] Completed on J0 in 0.03s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.TestRecyclingByteBlockAllocator [junit4:junit4] Completed on J1 in 0.06s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.codecs.pulsing.TestPulsingReuse [junit4:junit4] Completed on J0 in 0.02s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.TestSearch [junit4:junit4] Completed on J1 in 0.01s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestSameTokenSamePosition [junit4:junit4] Completed on J0 in 0.22s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestMatchAllDocsQuery [junit4:junit4] Completed on J1 in 0.03s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestNot [junit4:junit4] Completed on J0 in 0.05s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestSimilarity [junit4:junit4] Completed on J1 in 0.02s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestAutomatonQueryUnicode [junit4:junit4] Completed on J0 in 0.04s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.TestTopScoreDocCollector [junit4:junit4] Completed on J1 in 0.02s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.store.TestLock [junit4:junit4] Completed on J0 in 0.02s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.TestIntsRef [junit4:junit4] Completed on J1 in 0.05s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.util.TestPriorityQueue [junit4:junit4] Completed on J0 in 0.15s, 4 tests [junit4:junit4] [junit4:junit4] Suite:
