[Lucene.Net] [jira] [Commented] (LUCENENET-391) Luke.Net for Lucene.Net
[ https://issues.apache.org/jira/browse/LUCENENET-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009224#comment-13009224 ] Amanuel Workneh commented on LUCENENET-391: --- The bitbucket version is a WPF application and I suppose we want the resulting application to run under Mono. I suggest we use the Pasha Bizhan version. I have made a 2.9.2-version and if we agree that we want to continue with the Bizhan version work can begin. Luke.Net for Lucene.Net --- Key: LUCENENET-391 URL: https://issues.apache.org/jira/browse/LUCENENET-391 Project: Lucene.Net Issue Type: New Feature Components: Lucene.Net Contrib Reporter: Pasha Bizhan Assignee: Sergey Mirvoda Priority: Minor Labels: Luke.Net Fix For: Lucene.Net 2.9.4 Attachments: luke-net-bin.zip, luke-net-src.zip Create a port of Java Luke to .NET for use with Lucene.Net See attachments for a 1.4 compatible version or https://bitbucket.org/thoward/luke.net-incbuating for a partial implementation that is 2.9.2 compatible. The attached version was contributed by Pasha Bizhan, and the bitbucket version was contributed by Aaron Powell (above version is a fork, original at https://bitbucket.org/slace/luke.net). If source code from either is used, a software grant must be provided from the original authors. The final version should be 2.9.4 compatible and implement most or all features of Java Luke 1.0.1 (see http://code.google.com/p/luke/ ). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [Lucene.Net] Arithmetic Overflow
While I understand that and thank you for taking the time to respond, my concern was that passing a perfectly valid parameter leads to an exception. So this is bad design. Regards, Steve Hoff From: Digy digyd...@gmail.com To: lucene-net-dev@lucene.apache.org Date: 03/21/2011 01:53 PM Subject:RE: [Lucene.Net] Arithmetic Overflow This is an expected behaviour. You get arithmetic overflow since an array[MaxInt] is created in PriorityQueue to store the results. (Lucene doesn't know the result-count before iterating over the results). If you want to collect all results( say,not the top 10 or 100), you can use HitCollector. DIGY -Original Message- From: steven.h...@pattersoncompanies.com [mailto:steven.h...@pattersoncompanies.com] Sent: Monday, March 21, 2011 7:10 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Arithmetic Overflow I'm not sure how to report this or if this is working as intended, however using the recommended Search overload of IndexSearcher and passing Int32.MaxValue, results in an arithmetic overflow exception in PriorityQueue.Initialize(int maxSize). I tested this out on several platforms, including Windows 7 - 32, 64, Server 2003, Server 2008. Perhaps the parameter that is passed to the Search method should be updated to reflect a more realistic value? Regards, Steve Hoff NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer. NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer.
RE: [Lucene.Net] Arithmetic Overflow
No, I don't think it is a bad design. It could be limited to some number, but what would it be? 10,100,1000,100 or 1? Besides that you have other alternatives to use while searching. DIGY. -Original Message- From: steven.h...@pattersoncompanies.com [mailto:steven.h...@pattersoncompanies.com] Sent: Monday, March 21, 2011 9:16 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Arithmetic Overflow While I understand that and thank you for taking the time to respond, my concern was that passing a perfectly valid parameter leads to an exception. So this is bad design. Regards, Steve Hoff From: Digy digyd...@gmail.com To: lucene-net-dev@lucene.apache.org Date: 03/21/2011 01:53 PM Subject:RE: [Lucene.Net] Arithmetic Overflow This is an expected behaviour. You get arithmetic overflow since an array[MaxInt] is created in PriorityQueue to store the results. (Lucene doesn't know the result-count before iterating over the results). If you want to collect all results( say,not the top 10 or 100), you can use HitCollector. DIGY -Original Message- From: steven.h...@pattersoncompanies.com [mailto:steven.h...@pattersoncompanies.com] Sent: Monday, March 21, 2011 7:10 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Arithmetic Overflow I'm not sure how to report this or if this is working as intended, however using the recommended Search overload of IndexSearcher and passing Int32.MaxValue, results in an arithmetic overflow exception in PriorityQueue.Initialize(int maxSize). I tested this out on several platforms, including Windows 7 - 32, 64, Server 2003, Server 2008. Perhaps the parameter that is passed to the Search method should be updated to reflect a more realistic value? Regards, Steve Hoff NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer. NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer.
Re: [Lucene.Net] Arithmetic Overflow
I agree that it should not throw an overflow exception. That's not very helpful for debugging. The valid range of that parameter is essentially [0... Int32.MaxValue-1].. That's because it needs one extra slot in it's internal array, beyond the max size for juggling values during sort. The exception is thrown when it tries to setup the array to be the parameter value +1 to accommodate that... So the best we could do would be to throw a nicer exception when someone passes an invalid value. Until a nicer exception can be worked into the code, the documentation should be updated to reflect that limit... Thanks, Troy On Mon, Mar 21, 2011 at 12:15 PM, steven.h...@pattersoncompanies.com wrote: While I understand that and thank you for taking the time to respond, my concern was that passing a perfectly valid parameter leads to an exception. So this is bad design. Regards, Steve Hoff From: Digy digyd...@gmail.com To: lucene-net-dev@lucene.apache.org Date: 03/21/2011 01:53 PM Subject: RE: [Lucene.Net] Arithmetic Overflow This is an expected behaviour. You get arithmetic overflow since an array[MaxInt] is created in PriorityQueue to store the results. (Lucene doesn't know the result-count before iterating over the results). If you want to collect all results( say,not the top 10 or 100), you can use HitCollector. DIGY -Original Message- From: steven.h...@pattersoncompanies.com [mailto:steven.h...@pattersoncompanies.com] Sent: Monday, March 21, 2011 7:10 PM To: lucene-net-dev@lucene.apache.org Subject: RE: [Lucene.Net] Arithmetic Overflow I'm not sure how to report this or if this is working as intended, however using the recommended Search overload of IndexSearcher and passing Int32.MaxValue, results in an arithmetic overflow exception in PriorityQueue.Initialize(int maxSize). I tested this out on several platforms, including Windows 7 - 32, 64, Server 2003, Server 2008. Perhaps the parameter that is passed to the Search method should be updated to reflect a more realistic value? Regards, Steve Hoff NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer. NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer.
[Lucene.Net] [jira] [Commented] (LUCENENET-399) Port changes from Java Lucene 2.9.3 and 2.9.4 releases
[ https://issues.apache.org/jira/browse/LUCENENET-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009436#comment-13009436 ] Digy commented on LUCENENET-399: There are two public fields in TopDocs, totalHits and scoreDocs. Should we leave them as is for backward compatibility, or change to .Net style like TotalHits and ScoreDocs. (or support both of them) DIGY. Port changes from Java Lucene 2.9.3 and 2.9.4 releases -- Key: LUCENENET-399 URL: https://issues.apache.org/jira/browse/LUCENENET-399 Project: Lucene.Net Issue Type: Task Components: Lucene.Net Core, Lucene.Net Test Reporter: Troy Howard Assignee: Scott Lombard Fix For: Lucene.Net 2.9.4 Time Spent: 10h Remaining Estimate: 10h Port changes from Java Lucene 2.9.3 and 2.9.4 releases. The Lucene.Net 2.9.4 release will roll up the changes from both of those releases into one. Unit tests should be added or updated to reflect the changes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Created] (LUCENE-2979) Simplify configuration API of contrib Query Parser
Simplify configuration API of contrib Query Parser -- Key: LUCENE-2979 URL: https://issues.apache.org/jira/browse/LUCENE-2979 Project: Lucene - Java Issue Type: Improvement Components: contrib/* Affects Versions: 3.0, 2.9 Reporter: Adriano Crestani Fix For: 3.1, 4.0 The current configuration API is very complicated and inherit the concept used by Attribute API to store token information in token streams. However, the requirements for both (QP config and token stream) are not the same, so they shouldn't be using the same thing. I propose to simplify QP config and make it less scary for people intending to use contrib QP. The task is not difficult, it will just require a lot of code change and figure out the best way to do it. That's why it's a good candidate for a GSoC project. I would like to hear good proposals about how to make the API more friendly and less scaring :) -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6179 - Failure
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6179/ 1 tests failed. REGRESSION: org.apache.solr.cloud.CloudStateUpdateTest.testCoreRegistration Error Message: expected:2 but was:3 Stack Trace: junit.framework.AssertionFailedError: expected:2 but was:3 at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) at org.apache.solr.cloud.CloudStateUpdateTest.testCoreRegistration(CloudStateUpdateTest.java:208) Build Log (for compile errors): [...truncated 8709 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Solr-trunk - Build # 1449 - Still Failing
Build: https://hudson.apache.org/hudson/job/Solr-trunk/1449/ No tests ran. Build Log (for compile errors): [...truncated 19027 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2978) Upgrade benchmark from commons-compress-1.0 to commons-compress-1.1 for 15 times faster gzip decompression
[ https://issues.apache.org/jira/browse/LUCENE-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-2978: Description: In LUCENE-1540 TrecContentSource moved from Java's GZipInputStream to common-compress 1.0. This slowed down gzip decompression by a factor of 15. Upgrading to 1.1 solves this problem. I verified that the problem is only in GZIP, not in BZIP. On the way, as 1.1 introduced constants for the compression methods, the code can be made a bit nicer. was: In LUCENE-1540 TrecContentSource moved from Java's GZipInputStream to common-compress 1.1. This slowed down gzip decompression by a factor of 15. Upgrading to 1.0 solves this problem. I verified that the problem is only in GZIP, not in BZIP. On the way, as 1.1 introduced constants for the compression methods, the code can be made a bit nicer. Upgrade benchmark from commons-compress-1.0 to commons-compress-1.1 for 15 times faster gzip decompression -- Key: LUCENE-2978 URL: https://issues.apache.org/jira/browse/LUCENE-2978 Project: Lucene - Java Issue Type: Bug Components: contrib/benchmark Reporter: Doron Cohen Assignee: Doron Cohen Fix For: 3.2, 4.0 In LUCENE-1540 TrecContentSource moved from Java's GZipInputStream to common-compress 1.0. This slowed down gzip decompression by a factor of 15. Upgrading to 1.1 solves this problem. I verified that the problem is only in GZIP, not in BZIP. On the way, as 1.1 introduced constants for the compression methods, the code can be made a bit nicer. -- This message is automatically generated by JIRA. 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-2964) Allow benchmark tasks from alternative packages
[
https://issues.apache.org/jira/browse/LUCENE-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009060#comment-13009060
]
Doron Cohen commented on LUCENE-2964:
-
Thanks for reviewing.
bq. The CNFE message that you pass is already descriptive enough, IMO.
Agree, I'll change that.
bq. put AltTestTask an inner public static member of AltPackageTaskTest
This makes sense - but is tricky, as the alg line should now look like this:
{code}
String altTask = { AltPackageTaskTest$AltTest }; // inner class peculiarities
- '$' as separator
{code}
Which is rather not too nice (took me some time to figure why just
*AltPackageTaskTest.AltTest* fails).
But in addition, *$* causes the Algorithm's tokenizer to break that into two
task names, I am not sure it is worth to modify it for removing that test
class, but I'll give it a few more minutes.
Allow benchmark tasks from alternative packages
---
Key: LUCENE-2964
URL: https://issues.apache.org/jira/browse/LUCENE-2964
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/benchmark
Reporter: Doron Cohen
Assignee: Doron Cohen
Priority: Minor
Fix For: 3.2, 4.0
Attachments: LUCENE-2964.patch, LUCENE-2964.patch
Relax current limitation of all tasks in same package - that of PerfTask.
Add a property alt.tasks.packages - its value are comma separated full
package names.
If the task class is not found in the default package, an attempt is made to
load it from the alternate packages specified in that property.
--
This message is automatically generated by JIRA.
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-2964) Allow benchmark tasks from alternative packages
[
https://issues.apache.org/jira/browse/LUCENE-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009062#comment-13009062
]
Doron Cohen commented on LUCENE-2964:
-
Apparently using '$' is safe in that it is always correct as this is the
standard definition for inner class separator - see [Inner Classes
Specification | http://www.retrologic.com/innerclasses.doc7.html].
The required change to the Benchmark Algorithm is to define '$' as a word part,
by adding this to the Algorithm's tokenizer intialization:
{code}
stok.wordChars('$','$');
{code}
I am not sure about this.
It would allow easier creation of tasks as inner classes.
But this is mainly for tests I assume, because for real tasks one would want
them to read nicely - without that '$' and to have their own class file.
And making '$' a regular word char just for this test need, will prevent us
from adding some semantics to it in the future, should the need arise,
So, I rather keep the additional class file in the test package.
Allow benchmark tasks from alternative packages
---
Key: LUCENE-2964
URL: https://issues.apache.org/jira/browse/LUCENE-2964
Project: Lucene - Java
Issue Type: Improvement
Components: contrib/benchmark
Reporter: Doron Cohen
Assignee: Doron Cohen
Priority: Minor
Fix For: 3.2, 4.0
Attachments: LUCENE-2964.patch, LUCENE-2964.patch
Relax current limitation of all tasks in same package - that of PerfTask.
Add a property alt.tasks.packages - its value are comma separated full
package names.
If the task class is not found in the default package, an attempt is made to
load it from the alternate packages specified in that property.
--
This message is automatically generated by JIRA.
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-2454) Nested Document query support
[ https://issues.apache.org/jira/browse/LUCENE-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009071#comment-13009071 ] RynekMedyczny.pl commented on LUCENE-2454: -- Mark, do you have any plans for including this feature into the Lucene trunk? I think that this is a must have feature since tree structures are so common! Thank you in advance. Nested Document query support - Key: LUCENE-2454 URL: https://issues.apache.org/jira/browse/LUCENE-2454 Project: Lucene - Java Issue Type: New Feature Components: Search Affects Versions: 3.0.2 Reporter: Mark Harwood Assignee: Mark Harwood Priority: Minor Attachments: LuceneNestedDocumentSupport.zip A facility for querying nested documents in a Lucene index as outlined in http://www.slideshare.net/MarkHarwood/proposal-for-nested-document-support-in-lucene -- This message is automatically generated by JIRA. 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-2964) Allow benchmark tasks from alternative packages
[ https://issues.apache.org/jira/browse/LUCENE-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-2964: Attachment: LUCENE-2964.patch Updated patch, fixing per Shai suggestion on the exception. Planning to commit shortly. Allow benchmark tasks from alternative packages --- Key: LUCENE-2964 URL: https://issues.apache.org/jira/browse/LUCENE-2964 Project: Lucene - Java Issue Type: Improvement Components: contrib/benchmark Reporter: Doron Cohen Assignee: Doron Cohen Priority: Minor Fix For: 3.2, 4.0 Attachments: LUCENE-2964.patch, LUCENE-2964.patch, LUCENE-2964.patch Relax current limitation of all tasks in same package - that of PerfTask. Add a property alt.tasks.packages - its value are comma separated full package names. If the task class is not found in the default package, an attempt is made to load it from the alternate packages specified in that property. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (LUCENE-2454) Nested Document query support
On 3/21/11 10:51 AM, Dawid Weiss wrote: Is it just me, or was that last e-mail sent with the header: From: RynekMedyczny.pl (JIRA)j...@apache.org JIRA comment notifications put username in front of JIRA's own address. Apparently someone uses RynekMedyczny.pl as their username. This is weird :) I, for one, welcome RynekMedyczny.pl as a Solr user :) -- Best regards, Andrzej Bialecki ___. ___ ___ ___ _ _ __ [__ || __|__/|__||\/| Information Retrieval, Semantic Web ___|||__|| \| || | Embedded Unix, System Integration http://www.sigram.com Contact: info at sigram dot com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (LUCENE-2454) Nested Document query support
Oh, in this case I also welcome RynekMedyczny.pl as a Solr user ;) Dawid P.S. RynekMedyczny ~= HealthCareMarket On Mon, Mar 21, 2011 at 11:07 AM, Andrzej Bialecki a...@getopt.org wrote: On 3/21/11 10:51 AM, Dawid Weiss wrote: Is it just me, or was that last e-mail sent with the header: From: RynekMedyczny.pl (JIRA)j...@apache.org JIRA comment notifications put username in front of JIRA's own address. Apparently someone uses RynekMedyczny.pl as their username. This is weird :) I, for one, welcome RynekMedyczny.pl as a Solr user :) -- Best regards, Andrzej Bialecki ___. ___ ___ ___ _ _ __ [__ || __|__/|__||\/| Information Retrieval, Semantic Web ___|||__|| \| || | Embedded Unix, System Integration http://www.sigram.com Contact: info at sigram dot com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-2964) Allow benchmark tasks from alternative packages
[ https://issues.apache.org/jira/browse/LUCENE-2964?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen resolved LUCENE-2964. - Resolution: Fixed Committed: - r1083726 - 3x - r1083731 - trunk (Hudson's Lucene-Solr-tests-only-trunk #6185 passed the new Benchmarks tests.) Allow benchmark tasks from alternative packages --- Key: LUCENE-2964 URL: https://issues.apache.org/jira/browse/LUCENE-2964 Project: Lucene - Java Issue Type: Improvement Components: contrib/benchmark Reporter: Doron Cohen Assignee: Doron Cohen Priority: Minor Fix For: 3.2, 4.0 Attachments: LUCENE-2964.patch, LUCENE-2964.patch, LUCENE-2964.patch Relax current limitation of all tasks in same package - that of PerfTask. Add a property alt.tasks.packages - its value are comma separated full package names. If the task class is not found in the default package, an attempt is made to load it from the alternate packages specified in that property. -- This message is automatically generated by JIRA. 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-2454) Nested Document query support
[ https://issues.apache.org/jira/browse/LUCENE-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009111#comment-13009111 ] Mark Harwood commented on LUCENE-2454: -- bq. Mark, do you have any plans for including this feature into the Lucene trunk? That is my intention in providing it here. I had to work hard to convince my employer to let me release this as open source in the interests of seeing it updated/tested as core Lucene APIs change - and hopefully receive some improved support in IndexWriter flush control. Unfortunately it seems not everyone shares the pain when it comes to modelling richer data structures and seem content with the flat model we have in Lucene today. Code like this ends up in trunk when there is concensus so your support is welcome. While core Lucene adoption is a relatively simple technical task, Solr adoption feels like a much more disruptive change. Nested Document query support - Key: LUCENE-2454 URL: https://issues.apache.org/jira/browse/LUCENE-2454 Project: Lucene - Java Issue Type: New Feature Components: Search Affects Versions: 3.0.2 Reporter: Mark Harwood Assignee: Mark Harwood Priority: Minor Attachments: LuceneNestedDocumentSupport.zip A facility for querying nested documents in a Lucene index as outlined in http://www.slideshare.net/MarkHarwood/proposal-for-nested-document-support-in-lucene -- This message is automatically generated by JIRA. 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-2881) Track FieldInfo per segment instead of per-IW-session
[ https://issues.apache.org/jira/browse/LUCENE-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-2881: Attachment: LUCENE-2881.patch next iteration, I think we are ready to commit here. I added a couple of testcases regarding the fnx file and made sure they get deleted accordingly even if we fail with Exceptions during prepareCommit finishCommit. Moved the BW-Compat code for building the initial global map to SegmentInfos and cleaned up assertions in FieldInfos (also added the suggested assertion to FIs#putInternal). To prevent that we miss a fnx file if we open an old index, write the fnx file and keep that SIS in memory with format set to some old version I removed the check if we are on 4.0 index but used the latestGlobalFieldNumberVersion which is kept consistent and only include the file if its not set to 0. I run whileTrue tests on this patch now for a while and things are looking good from my side. Mike if you have time let beast chew it again. If its fine I will commit tomorrow. Track FieldInfo per segment instead of per-IW-session - Key: LUCENE-2881 URL: https://issues.apache.org/jira/browse/LUCENE-2881 Project: Lucene - Java Issue Type: Improvement Affects Versions: Realtime Branch, CSF branch, 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: Realtime Branch, CSF branch, 4.0 Attachments: LUCENE-2881.patch, LUCENE-2881.patch, LUCENE-2881.patch, LUCENE-2881.patch, lucene-2881.patch, lucene-2881.patch, lucene-2881.patch, lucene-2881.patch, lucene-2881.patch Currently FieldInfo is tracked per IW session to guarantee consistent global field-naming / ordering. IW carries FI instances over from previous segments which also carries over field properties like isIndexed etc. While having consistent field ordering per IW session appears to be important due to bulk merging stored fields etc. carrying over other properties might become problematic with Lucene's Codec support. Codecs that rely on consistent properties in FI will fail if FI properties are carried over. The DocValuesCodec (DocValuesBranch) for instance writes files per segment and field (using the field id within the file name). Yet, if a segment has no DocValues indexed in a particular segment but a previous segment in the same IW session had DocValues, FieldInfo#docValues will be true since those values are reused from previous segments. We already work around this limitation in SegmentInfo with properties like hasVectors or hasProx which is really something we should manage per Codec Segment. Ideally FieldInfo would be managed per Segment and Codec such that its properties are valid per segment. It also seems to be necessary to bind FieldInfoS to SegmentInfo logically since its really just per segment metadata. -- This message is automatically generated by JIRA. 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-2958) WriteLineDocTask improvements
[ https://issues.apache.org/jira/browse/LUCENE-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-2958: Attachment: LUCENE-2958.patch Hmmm, while reviewing again before committing I noticed that the HeaderLineParser constructor never assigns FieldName.PROP in posToF. I intended to do this but forgot. Indeed, emma shows that Properties handling in LineDocSource is not tested. So I enhanced LineDocSourceTest to also test for nonstandard fields and for properties. The test failes as expected, and the fix was trivial. Attaching updated patch, planning to commit this shortly. WriteLineDocTask improvements - Key: LUCENE-2958 URL: https://issues.apache.org/jira/browse/LUCENE-2958 Project: Lucene - Java Issue Type: Improvement Components: contrib/benchmark Reporter: Doron Cohen Assignee: Doron Cohen Priority: Minor Fix For: 3.2, 4.0 Attachments: LUCENE-2958.patch, LUCENE-2958.patch, LUCENE-2958.patch, LUCENE-2958.patch, LUCENE-2958.patch, LUCENE-2958.patch Make WriteLineDocTask and LineDocSource more flexible/extendable: * allow to emit lines also for empty docs (keep current behavior as default) * allow more/less/other fields -- This message is automatically generated by JIRA. 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] (LUCENE-2944) BytesRef reuse bugs in QueryParser and analysis.jsp
[
https://issues.apache.org/jira/browse/LUCENE-2944?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-2944.
-
Resolution: Fixed
Committed revision 1083784.
BytesRef reuse bugs in QueryParser and analysis.jsp
---
Key: LUCENE-2944
URL: https://issues.apache.org/jira/browse/LUCENE-2944
Project: Lucene - Java
Issue Type: Bug
Reporter: Robert Muir
Assignee: Robert Muir
Fix For: 4.0
Attachments: LUCENE-2944.patch, LUCENE-2944.patch, LUCENE-2944.patch,
LUCENE-2944.patch, LUCENE-2944.patch, LUCENE-2944_option2.patch
Some code uses BytesRef as if it were a String, in this case consumers of
TermToBytesRefAttribute.
The thing is, while our general implementation works on char[] and then
populates the consumers BytesRef,
not all TermToBytesRefAttribute implementations do this, specifically ICU
collation, it reuses the bytes and simply sets the pointers:
{noformat}
@Override
public int toBytesRef(BytesRef target) {
collator.getRawCollationKey(toString(), key);
target.bytes = key.bytes;
target.offset = 0;
target.length = key.size;
return target.hashCode();
}
{noformat}
Most of the blame falls on me as I added this to the queryparser in
LUCENE-2514.
Attached is a patch so that these consumers re-use a 'spare' and copy the
bytes when they are going to make a long lasting object such as a Term.
--
This message is automatically generated by JIRA.
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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6189 - Failure
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6189/
No tests ran.
Build Log (for compile errors):
[...truncated 49 lines...]
clean:
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build
clean:
clean:
[echo] Building analyzers-common...
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/analysis/build/common
[echo] Building analyzers-icu...
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/analysis/build/icu
[echo] Building analyzers-phonetic...
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/analysis/build/phonetic
[echo] Building analyzers-smartcn...
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/analysis/build/smartcn
[echo] Building analyzers-stempel...
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/analysis/build/stempel
[echo] Building benchmark...
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/modules/benchmark/build
clean-contrib:
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/contrib/analysis-extras/build
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/contrib/analysis-extras/lucene-libs
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/contrib/clustering/build
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/contrib/dataimporthandler/target
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/contrib/extraction/build
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/contrib/uima/build
clean:
[delete] Deleting directory
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/solr/build
BUILD SUCCESSFUL
Total time: 3 seconds
+ cd
/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene
+ JAVA_HOME=/home/hudson/tools/java/latest1.5
/home/hudson/tools/ant/latest1.7/bin/ant compile compile-test build-contrib
Buildfile: build.xml
jflex-uptodate-check:
jflex-notice:
javacc-uptodate-check:
javacc-notice:
init:
clover.setup:
clover.info:
[echo]
[echo] Clover not found. Code coverage reports disabled.
[echo]
clover:
common.compile-core:
[mkdir] Created dir:
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build/classes/java
[javac] Compiling 508 source files to
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/build/classes/java
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/src/java/org/apache/lucene/util/Version.java:80:
warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac] public boolean onOrAfter(Version other) {
[javac] ^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/src/java/org/apache/lucene/analysis/tokenattributes/CharTermAttributeImpl.java:82:
method does not override a method from its superclass
[javac] @Override
[javac]^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/src/java/org/apache/lucene/analysis/tokenattributes/CharTermAttributeImpl.java:87:
method does not override a method from its superclass
[javac] @Override
[javac]^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/src/java/org/apache/lucene/queryParser/CharStream.java:34:
warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac] int getColumn();
[javac] ^
[javac]
/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-tests-only-trunk/checkout/lucene/src/java/org/apache/lucene/queryParser/CharStream.java:41:
warning: [dep-ann] deprecated name isnt annotated with @Deprecated
[javac] int getLine();
[javac] ^
[javac] Note: Some input files use or override a deprecated API.
[javac] Note: Recompile with -Xlint:deprecation for details.
[javac] 2 errors
[...truncated 10 lines...]
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For
Re: IndexReader.indexExists declares throwing IOE, but never does
Technically, there's a big difference between I checked, and there was no index, and I was unable to check the disk because file system went BANG!. So the proper behaviour is to return false IOE (on proper occasion)? On Mon, Mar 21, 2011 at 13:53, Michael McCandless luc...@mikemccandless.com wrote: On Mon, Mar 21, 2011 at 12:52 AM, Shai Erera ser...@gmail.com wrote: Can we remove the declaration? The method never throws IOE, but instead catches it and returns false. I think it's reasonable that such a method will not throw exceptions. +1 -- Mike http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Kirill Zakharenko/Кирилл Захаренко E-Mail/Jabber: ear...@gmail.com Phone: +7 (495) 683-567-4 ICQ: 104465785 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: IndexReader.indexExists declares throwing IOE, but never does
2011/3/21 Earwin Burrfoot ear...@gmail.com: Technically, there's a big difference between I checked, and there was no index, and I was unable to check the disk because file system went BANG!. So the proper behaviour is to return false IOE (on proper occasion)? +1 to throw the exception when proper to do so Otherwise please keep the throws declaration so that you won't break public APIs if this changes implementation. On Mon, Mar 21, 2011 at 13:53, Michael McCandless luc...@mikemccandless.com wrote: On Mon, Mar 21, 2011 at 12:52 AM, Shai Erera ser...@gmail.com wrote: Can we remove the declaration? The method never throws IOE, but instead catches it and returns false. I think it's reasonable that such a method will not throw exceptions. +1 -- Mike http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Kirill Zakharenko/Кирилл Захаренко E-Mail/Jabber: ear...@gmail.com Phone: +7 (495) 683-567-4 ICQ: 104465785 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2454) Nested Document query support
[ https://issues.apache.org/jira/browse/LUCENE-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009141#comment-13009141 ] Jamal Natour commented on LUCENE-2454: -- Mark, For my project this is a must have feature that could decide the adoption of SOLR. What do think is the best way to help ensure this gets incorporated into SOLR? Thank you, Jamal Nested Document query support - Key: LUCENE-2454 URL: https://issues.apache.org/jira/browse/LUCENE-2454 Project: Lucene - Java Issue Type: New Feature Components: Search Affects Versions: 3.0.2 Reporter: Mark Harwood Assignee: Mark Harwood Priority: Minor Attachments: LuceneNestedDocumentSupport.zip A facility for querying nested documents in a Lucene index as outlined in http://www.slideshare.net/MarkHarwood/proposal-for-nested-document-support-in-lucene -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: IndexReader.indexExists declares throwing IOE, but never does
So the proper behaviour is to return false IOE (on proper occasion)? I don't object to it, as I think it's reasonable (as today we may be hiding some info from the app). However, given that today we never throw IOE, and that if we start doing so, we'll change runtime behavior, I lean towards keeping the method simple and remove the throws declaration. Well, it's either we change the impl to throw IOE, or remove the declaration altogether. Changing the impl to throw IOE on proper occasion might be problematic -- IndexNotFoundException is thrown when an empty index directory was given, however by its Javadocs, it can also indicate the index is corrupted. Perhaps the jdocs are wrong and it's thrown only if the index directory is empty, or no segments files are found. If that's the case, then we should change its javadocs. Otherwise, it will be difficult to know whether the INFE indicates an empty directory, for which you'll want to return false, or a corrupt index, for which you'll want to throw the exception. Besides, I consider this method almost like File.exists() which doesn't throw an exception. If indexExists() returns false, the app can decide to investigate further by trying to open IndexReader or read the SegmentInfos. But the API as-is needs to be simple IMO. Otherwise please keep the throws declaration so that you won't break public APIs if this changes implementation. Removing the throws declaration doesn't break apps. In the worse case, they'll have a catch block which is redundant? Shai On Mon, Mar 21, 2011 at 4:12 PM, Sanne Grinovero sanne.grinov...@gmail.comwrote: 2011/3/21 Earwin Burrfoot ear...@gmail.com: Technically, there's a big difference between I checked, and there was no index, and I was unable to check the disk because file system went BANG!. So the proper behaviour is to return false IOE (on proper occasion)? +1 to throw the exception when proper to do so Otherwise please keep the throws declaration so that you won't break public APIs if this changes implementation. On Mon, Mar 21, 2011 at 13:53, Michael McCandless luc...@mikemccandless.com wrote: On Mon, Mar 21, 2011 at 12:52 AM, Shai Erera ser...@gmail.com wrote: Can we remove the declaration? The method never throws IOE, but instead catches it and returns false. I think it's reasonable that such a method will not throw exceptions. +1 -- Mike http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Kirill Zakharenko/Кирилл Захаренко E-Mail/Jabber: ear...@gmail.com Phone: +7 (495) 683-567-4 ICQ: 104465785 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: IndexReader.indexExists declares throwing IOE, but never does
2011/3/21 Shai Erera ser...@gmail.com: So the proper behaviour is to return false IOE (on proper occasion)? I don't object to it, as I think it's reasonable (as today we may be hiding some info from the app). However, given that today we never throw IOE, and that if we start doing so, we'll change runtime behavior, I lean towards keeping the method simple and remove the throws declaration. Well, it's either we change the impl to throw IOE, or remove the declaration altogether. Changing the impl to throw IOE on proper occasion might be problematic -- IndexNotFoundException is thrown when an empty index directory was given, however by its Javadocs, it can also indicate the index is corrupted. Perhaps the jdocs are wrong and it's thrown only if the index directory is empty, or no segments files are found. If that's the case, then we should change its javadocs. Otherwise, it will be difficult to know whether the INFE indicates an empty directory, for which you'll want to return false, or a corrupt index, for which you'll want to throw the exception. Besides, I consider this method almost like File.exists() which doesn't throw an exception. If indexExists() returns false, the app can decide to investigate further by trying to open IndexReader or read the SegmentInfos. But the API as-is needs to be simple IMO. good points, I withdraw my previous objection :) Otherwise please keep the throws declaration so that you won't break public APIs if this changes implementation. Removing the throws declaration doesn't break apps. In the worse case, they'll have a catch block which is redundant? yes you wouldn't make any harm now, but if you release it without, and then figure you actually need to add it back in future, people might have code which is not handling it. I'm looking into Lucene 3.0.3 and the IOException it *is* actually needed, not sure what was changed in the version this is referring to, but as it used to throw it (and needing it), I think it's quite possible this need is not so remote. Regards, Sanne Shai On Mon, Mar 21, 2011 at 4:12 PM, Sanne Grinovero sanne.grinov...@gmail.com wrote: 2011/3/21 Earwin Burrfoot ear...@gmail.com: Technically, there's a big difference between I checked, and there was no index, and I was unable to check the disk because file system went BANG!. So the proper behaviour is to return false IOE (on proper occasion)? +1 to throw the exception when proper to do so Otherwise please keep the throws declaration so that you won't break public APIs if this changes implementation. On Mon, Mar 21, 2011 at 13:53, Michael McCandless luc...@mikemccandless.com wrote: On Mon, Mar 21, 2011 at 12:52 AM, Shai Erera ser...@gmail.com wrote: Can we remove the declaration? The method never throws IOE, but instead catches it and returns false. I think it's reasonable that such a method will not throw exceptions. +1 -- Mike http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Kirill Zakharenko/Кирилл Захаренко E-Mail/Jabber: ear...@gmail.com Phone: +7 (495) 683-567-4 ICQ: 104465785 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2454) Nested Document query support
[ https://issues.apache.org/jira/browse/LUCENE-2454?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009163#comment-13009163 ] Mark Harwood commented on LUCENE-2454: -- Lucene does not dictate a schema and so using this approach to index design/querying is not a problem with base Lucene. Solr, however does introduce a schema and much more that assumes a flat model. In the opening chapters of the Solr 1.4 Enterprise Search Server book the authors take the time to discuss the modelling limitations of this flat model and acknowledge this as an issue. The impact of adopting nested documents in Solr at this stage would be very large. There may be ways you can overcome some of your issues without requiring nested documents (using phrase/span queries or combining tokens from multiple fields in Solr) but in my experience these are often poor alternatives if richer structures are important. Cheers Mark Nested Document query support - Key: LUCENE-2454 URL: https://issues.apache.org/jira/browse/LUCENE-2454 Project: Lucene - Java Issue Type: New Feature Components: Search Affects Versions: 3.0.2 Reporter: Mark Harwood Assignee: Mark Harwood Priority: Minor Attachments: LuceneNestedDocumentSupport.zip A facility for querying nested documents in a Lucene index as outlined in http://www.slideshare.net/MarkHarwood/proposal-for-nested-document-support-in-lucene -- This message is automatically generated by JIRA. 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-2952) Make license checking/maintenance easier/automated
[ https://issues.apache.org/jira/browse/LUCENE-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009169#comment-13009169 ] Grant Ingersoll commented on LUCENE-2952: - Third time is the charm. I don't really care where it lives and it sounds like tools makes sense. Not sure why I didn't notice that sooner. I'll take care of it later today. Make license checking/maintenance easier/automated -- Key: LUCENE-2952 URL: https://issues.apache.org/jira/browse/LUCENE-2952 Project: Lucene - Java Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 3.2, 4.0 Attachments: LUCENE-2952.patch, LUCENE-2952.patch, LUCENE-2952.patch, LUCENE-2952.patch, LUCENE-2952.patch, LUCENE-2952.patch, LUCENE-2952.patch Instead of waiting until release to check licenses are valid, we should make it a part of our build process to ensure that all dependencies have proper licenses, etc. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: IndexReader.indexExists declares throwing IOE, but never does
2011/3/21 Shai Erera ser...@gmail.com: So the proper behaviour is to return false IOE (on proper occasion)? I don't object to it, as I think it's reasonable (as today we may be hiding some info from the app). However, given that today we never throw IOE, and that if we start doing so, we'll change runtime behavior, I lean towards keeping the method simple and remove the throws declaration. Well, it's either we change the impl to throw IOE, or remove the declaration altogether. Changing the impl to throw IOE on proper occasion might be problematic -- IndexNotFoundException is thrown when an empty index directory was given, however by its Javadocs, it can also indicate the index is corrupted. Perhaps the jdocs are wrong and it's thrown only if the index directory is empty, or no segments files are found. If that's the case, then we should change its javadocs. Otherwise, it will be difficult to know whether the INFE indicates an empty directory, for which you'll want to return false, or a corrupt index, for which you'll want to throw the exception. Besides, I consider this method almost like File.exists() which doesn't throw an exception. If indexExists() returns false, the app can decide to investigate further by trying to open IndexReader or read the SegmentInfos. But the API as-is needs to be simple IMO. File.exists() parallel is a good one. So, maybe, it's ok ) Otherwise please keep the throws declaration so that you won't break public APIs if this changes implementation. Removing the throws declaration doesn't break apps. In the worse case, they'll have a catch block which is redundant? Shai On Mon, Mar 21, 2011 at 4:12 PM, Sanne Grinovero sanne.grinov...@gmail.com wrote: 2011/3/21 Earwin Burrfoot ear...@gmail.com: Technically, there's a big difference between I checked, and there was no index, and I was unable to check the disk because file system went BANG!. So the proper behaviour is to return false IOE (on proper occasion)? +1 to throw the exception when proper to do so Otherwise please keep the throws declaration so that you won't break public APIs if this changes implementation. On Mon, Mar 21, 2011 at 13:53, Michael McCandless luc...@mikemccandless.com wrote: On Mon, Mar 21, 2011 at 12:52 AM, Shai Erera ser...@gmail.com wrote: Can we remove the declaration? The method never throws IOE, but instead catches it and returns false. I think it's reasonable that such a method will not throw exceptions. +1 -- Mike http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Kirill Zakharenko/Кирилл Захаренко E-Mail/Jabber: ear...@gmail.com Phone: +7 (495) 683-567-4 ICQ: 104465785 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Kirill Zakharenko/Кирилл Захаренко E-Mail/Jabber: ear...@gmail.com Phone: +7 (495) 683-567-4 ICQ: 104465785 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2952) Make license checking/maintenance easier/automated
[ https://issues.apache.org/jira/browse/LUCENE-2952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009173#comment-13009173 ] Uwe Schindler commented on LUCENE-2952: --- Unfortunately as analyzers moved to modules in trunk, so the tools folder is no longer in trunk's lucene/src. But we should use the same concept, its used at different places, e.g. in ICU contrib, StandarAnalyzer and other autogenerated code. I can help setting it up again. Make license checking/maintenance easier/automated -- Key: LUCENE-2952 URL: https://issues.apache.org/jira/browse/LUCENE-2952 Project: Lucene - Java Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Priority: Minor Fix For: 3.2, 4.0 Attachments: LUCENE-2952.patch, LUCENE-2952.patch, LUCENE-2952.patch, LUCENE-2952.patch, LUCENE-2952.patch, LUCENE-2952.patch, LUCENE-2952.patch Instead of waiting until release to check licenses are valid, we should make it a part of our build process to ensure that all dependencies have proper licenses, etc. -- This message is automatically generated by JIRA. 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] (LUCENE-2958) WriteLineDocTask improvements
[ https://issues.apache.org/jira/browse/LUCENE-2958?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen resolved LUCENE-2958. - Resolution: Fixed Committed: - r1083789 - 3x - r1083812 - 3x undo added unused imports - r1083816 - trunk Thanks Shai and Mike for reviewing and suggestions! WriteLineDocTask improvements - Key: LUCENE-2958 URL: https://issues.apache.org/jira/browse/LUCENE-2958 Project: Lucene - Java Issue Type: Improvement Components: contrib/benchmark Reporter: Doron Cohen Assignee: Doron Cohen Priority: Minor Fix For: 3.2, 4.0 Attachments: LUCENE-2958.patch, LUCENE-2958.patch, LUCENE-2958.patch, LUCENE-2958.patch, LUCENE-2958.patch, LUCENE-2958.patch Make WriteLineDocTask and LineDocSource more flexible/extendable: * allow to emit lines also for empty docs (keep current behavior as default) * allow more/less/other fields -- This message is automatically generated by JIRA. 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-2978) Upgrade benchmark from commons-compress-1.0 to commons-compress-1.1 for 15 times faster gzip decompression
[ https://issues.apache.org/jira/browse/LUCENE-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Doron Cohen updated LUCENE-2978: Attachment: LUCENE-2978.patch Trivial patch for trunk. Upgrade benchmark from commons-compress-1.0 to commons-compress-1.1 for 15 times faster gzip decompression -- Key: LUCENE-2978 URL: https://issues.apache.org/jira/browse/LUCENE-2978 Project: Lucene - Java Issue Type: Bug Components: contrib/benchmark Reporter: Doron Cohen Assignee: Doron Cohen Fix For: 3.2, 4.0 Attachments: LUCENE-2978.patch In LUCENE-1540 TrecContentSource moved from Java's GZipInputStream to common-compress 1.0. This slowed down gzip decompression by a factor of 15. Upgrading to 1.1 solves this problem. I verified that the problem is only in GZIP, not in BZIP. On the way, as 1.1 introduced constants for the compression methods, the code can be made a bit nicer. -- This message is automatically generated by JIRA. 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
Index File
Hi All, I have created Index folder, and i tried to open .CFS,.CFX,.GEN, segments file with notpad . but they are unreadable. i want to see their structure for my sample directory which i have passed to Indexfiles . ihave red this http://lucene.apache.org/java/3_0_3/fileformats.html and i know what Index should has. is there any way to see created index? thanks in advance . Peace. -Soheila D.
[jira] [Commented] (LUCENE-2894) Use of google-code-prettify for Lucene/Solr Javadoc
[ https://issues.apache.org/jira/browse/LUCENE-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009240#comment-13009240 ] Yonik Seeley commented on LUCENE-2894: -- bq. Do you mean Solr javadocs see the prettify stuff under lucene/ also? Yep, seems reasonable. Use of google-code-prettify for Lucene/Solr Javadoc --- Key: LUCENE-2894 URL: https://issues.apache.org/jira/browse/LUCENE-2894 Project: Lucene - Java Issue Type: Improvement Components: Javadocs Reporter: Koji Sekiguchi Assignee: Koji Sekiguchi Priority: Blocker Fix For: 3.1, 4.0 Attachments: LUCENE-2894-solr-analysis-AtoC.patch, LUCENE-2894-solr-analysis-DtoH.patch, LUCENE-2894-solr-analysis-ItoN.patch, LUCENE-2894-solr-analysis-OtoR.patch, LUCENE-2894-solr-analysis-StoZ.patch, LUCENE-2894.patch, LUCENE-2894.patch, LUCENE-2894.patch, LUCENE-2894.patch, LUCENE-2894.patch, LUCENE-2894.patch My company, RONDHUIT uses google-code-prettify (Apache License 2.0) in Javadoc for syntax highlighting: http://www.rondhuit-demo.com/RCSS/api/com/rondhuit/solr/analysis/JaReadingSynonymFilterFactory.html I think we can use it for Lucene javadoc (java sample code in overview.html etc) and Solr javadoc (Analyzer Factories etc) to improve or simplify our life. -- This message is automatically generated by JIRA. 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] [Reopened] (LUCENE-2973) Source distribution packaging targets should make a tarball from svn export
[
https://issues.apache.org/jira/browse/LUCENE-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe reopened LUCENE-2973:
-
The subversion {{export}} command has a {{--native-eol}} parameter:
{noformat}
--native-eol ARG : use a different EOL marker than the standard
system marker for files with the svn:eol-style
property set to 'native'.
ARG may be one of 'LF', 'CR', 'CRLF'
{noformat}
Solr's {{package-src}} and Lucene's {{dist-src}} targets should be made to use
this parameter with the {{LF}} arg, so that the source packages can be
consistently produced regardless of platform.
Source distribution packaging targets should make a tarball from svn export
-
Key: LUCENE-2973
URL: https://issues.apache.org/jira/browse/LUCENE-2973
Project: Lucene - Java
Issue Type: Improvement
Components: Build
Affects Versions: 3.1, 3.2, 4.0
Reporter: Steven Rowe
Assignee: Steven Rowe
Priority: Blocker
Fix For: 3.1, 3.2, 4.0
Attachments: LUCENE-2973.patch, LUCENE-2973.patch, LUCENE-2973.patch,
LUCENE-2973.patch, LUCENE-2973.patch, LUCENE-2973.patch, LUCENE-2973.patch
Instead of picking and choosing which stuff to include from a local working
copy, Lucene's dist-src/package-tgz-src target and Solr's package-src target
should simply perform svn export with the same revision and URL as the
local working copy.
--
This message is automatically generated by JIRA.
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-2978) Upgrade benchmark from commons-compress-1.0 to commons-compress-1.1 for 15 times faster gzip decompression
[ https://issues.apache.org/jira/browse/LUCENE-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009263#comment-13009263 ] Shai Erera commented on LUCENE-2978: I remember seeing a compress-1.1 jar under Solr somewhere. Can u plz check if we can use only one of them under Lucene/Solr? I've been thinking for some time that we need a module with common libraries used throughout the project. Something w/o code, only jars. I think we have several copies of some jars today, especially Apache ones. Consolidate all of them in one place will be great. We can do this in a separate issue though… Upgrade benchmark from commons-compress-1.0 to commons-compress-1.1 for 15 times faster gzip decompression -- Key: LUCENE-2978 URL: https://issues.apache.org/jira/browse/LUCENE-2978 Project: Lucene - Java Issue Type: Bug Components: contrib/benchmark Reporter: Doron Cohen Assignee: Doron Cohen Fix For: 3.2, 4.0 Attachments: LUCENE-2978.patch In LUCENE-1540 TrecContentSource moved from Java's GZipInputStream to common-compress 1.0. This slowed down gzip decompression by a factor of 15. Upgrading to 1.1 solves this problem. I verified that the problem is only in GZIP, not in BZIP. On the way, as 1.1 introduced constants for the compression methods, the code can be made a bit nicer. -- This message is automatically generated by JIRA. 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
[Lucene.Net] [jira] [Commented] (LUCENENET-391) Luke.Net for Lucene.Net
[ https://issues.apache.org/jira/browse/LUCENENET-391?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009268#comment-13009268 ] Troy Howard commented on LUCENENET-391: --- Amanuel: +1 Agreed Luke.Net for Lucene.Net --- Key: LUCENENET-391 URL: https://issues.apache.org/jira/browse/LUCENENET-391 Project: Lucene.Net Issue Type: New Feature Components: Lucene.Net Contrib Reporter: Pasha Bizhan Assignee: Sergey Mirvoda Priority: Minor Labels: Luke.Net Fix For: Lucene.Net 2.9.4 Attachments: luke-net-bin.zip, luke-net-src.zip Create a port of Java Luke to .NET for use with Lucene.Net See attachments for a 1.4 compatible version or https://bitbucket.org/thoward/luke.net-incbuating for a partial implementation that is 2.9.2 compatible. The attached version was contributed by Pasha Bizhan, and the bitbucket version was contributed by Aaron Powell (above version is a fork, original at https://bitbucket.org/slace/luke.net). If source code from either is used, a software grant must be provided from the original authors. The final version should be 2.9.4 compatible and implement most or all features of Java Luke 1.0.1 (see http://code.google.com/p/luke/ ). -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
RE: [Lucene.Net] Arithmetic Overflow
This is an expected behaviour. You get arithmetic overflow since an array[MaxInt] is created in PriorityQueue to store the results. (Lucene doesn't know the result-count before iterating over the results). If you want to collect all results( say,not the top 10 or 100), you can use HitCollector. DIGY -Original Message- From: steven.h...@pattersoncompanies.com [mailto:steven.h...@pattersoncompanies.com] Sent: Monday, March 21, 2011 7:10 PM To: lucene-net-...@lucene.apache.org Subject: RE: [Lucene.Net] Arithmetic Overflow I'm not sure how to report this or if this is working as intended, however using the recommended Search overload of IndexSearcher and passing Int32.MaxValue, results in an arithmetic overflow exception in PriorityQueue.Initialize(int maxSize). I tested this out on several platforms, including Windows 7 - 32, 64, Server 2003, Server 2008. Perhaps the parameter that is passed to the Search method should be updated to reflect a more realistic value? Regards, Steve Hoff NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer.
[jira] [Commented] (LUCENE-2978) Upgrade benchmark from commons-compress-1.0 to commons-compress-1.1 for 15 times faster gzip decompression
[ https://issues.apache.org/jira/browse/LUCENE-2978?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009321#comment-13009321 ] Doron Cohen commented on LUCENE-2978: - bq. Consolidate all of them in one place will be great. We can do this in a separate issue though I think SOLR-2435 deals with this. In this issue I rather get this problem fixed asap so that benchmark performs best. Upgrade benchmark from commons-compress-1.0 to commons-compress-1.1 for 15 times faster gzip decompression -- Key: LUCENE-2978 URL: https://issues.apache.org/jira/browse/LUCENE-2978 Project: Lucene - Java Issue Type: Bug Components: contrib/benchmark Reporter: Doron Cohen Assignee: Doron Cohen Fix For: 3.2, 4.0 Attachments: LUCENE-2978.patch In LUCENE-1540 TrecContentSource moved from Java's GZipInputStream to common-compress 1.0. This slowed down gzip decompression by a factor of 15. Upgrading to 1.1 solves this problem. I verified that the problem is only in GZIP, not in BZIP. On the way, as 1.1 introduced constants for the compression methods, the code can be made a bit nicer. -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6200 - Failure
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6200/ 2 tests failed. REGRESSION: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) REGRESSION: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
Re: Index File
Hi, 2011/3/21 soheila dehghanzadeh sally...@gmail.com: Hi All, I have created Index folder, and i tried to open .CFS,.CFX,.GEN, segments file with notpad . but they are unreadable. i want to see their structure for my sample directory which i have passed to Indexfiles . ihave red this http://lucene.apache.org/java/3_0_3/fileformats.html and i know what Index should has. is there any way to see created index? yes, use the force :) http://code.google.com/p/luke/ Regards, Sanne thanks in advance . Peace. -Soheila D. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-3.x - Build # 6184 - Failure
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6184/ 2 tests failed. REGRESSION: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) REGRESSION: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
RE: [Lucene.Net] Arithmetic Overflow
Is -for ex- MaxInt/2 a valid value? You can get easily an OOM exception( and the worst case would be getting sporadic OOM when search fequency increases). DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Monday, March 21, 2011 9:43 PM To: lucene-net-...@lucene.apache.org Subject: Re: [Lucene.Net] Arithmetic Overflow I agree that it should not throw an overflow exception. That's not very helpful for debugging. The valid range of that parameter is essentially [0... Int32.MaxValue-1].. That's because it needs one extra slot in it's internal array, beyond the max size for juggling values during sort. The exception is thrown when it tries to setup the array to be the parameter value +1 to accommodate that... So the best we could do would be to throw a nicer exception when someone passes an invalid value. Until a nicer exception can be worked into the code, the documentation should be updated to reflect that limit... Thanks, Troy On Mon, Mar 21, 2011 at 12:15 PM, steven.h...@pattersoncompanies.com wrote: While I understand that and thank you for taking the time to respond, my concern was that passing a perfectly valid parameter leads to an exception. So this is bad design. Regards, Steve Hoff From: Digy digyd...@gmail.com To: lucene-net-...@lucene.apache.org Date: 03/21/2011 01:53 PM Subject:RE: [Lucene.Net] Arithmetic Overflow This is an expected behaviour. You get arithmetic overflow since an array[MaxInt] is created in PriorityQueue to store the results. (Lucene doesn't know the result-count before iterating over the results). If you want to collect all results( say,not the top 10 or 100), you can use HitCollector. DIGY -Original Message- From: steven.h...@pattersoncompanies.com [mailto:steven.h...@pattersoncompanies.com] Sent: Monday, March 21, 2011 7:10 PM To: lucene-net-...@lucene.apache.org Subject: RE: [Lucene.Net] Arithmetic Overflow I'm not sure how to report this or if this is working as intended, however using the recommended Search overload of IndexSearcher and passing Int32.MaxValue, results in an arithmetic overflow exception in PriorityQueue.Initialize(int maxSize). I tested this out on several platforms, including Windows 7 - 32, 64, Server 2003, Server 2008. Perhaps the parameter that is passed to the Search method should be updated to reflect a more realistic value? Regards, Steve Hoff NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer. NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer.
[jira] [Commented] (LUCENE-2881) Track FieldInfo per segment instead of per-IW-session
[ https://issues.apache.org/jira/browse/LUCENE-2881?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009340#comment-13009340 ] Michael McCandless commented on LUCENE-2881: OK beast chewed on this for a few hours -- ran all (Lucene + Solr) tests 144 times. The UIMAUpdateRequestProcessorTest had a number of failures, but I suspect they are unrelated. (They could also be due to how I run the test -- I'm using the python runner from luceneutil). So I think it's good! I'll review the patch one more time... Track FieldInfo per segment instead of per-IW-session - Key: LUCENE-2881 URL: https://issues.apache.org/jira/browse/LUCENE-2881 Project: Lucene - Java Issue Type: Improvement Affects Versions: Realtime Branch, CSF branch, 4.0 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: Realtime Branch, CSF branch, 4.0 Attachments: LUCENE-2881.patch, LUCENE-2881.patch, LUCENE-2881.patch, LUCENE-2881.patch, lucene-2881.patch, lucene-2881.patch, lucene-2881.patch, lucene-2881.patch, lucene-2881.patch Currently FieldInfo is tracked per IW session to guarantee consistent global field-naming / ordering. IW carries FI instances over from previous segments which also carries over field properties like isIndexed etc. While having consistent field ordering per IW session appears to be important due to bulk merging stored fields etc. carrying over other properties might become problematic with Lucene's Codec support. Codecs that rely on consistent properties in FI will fail if FI properties are carried over. The DocValuesCodec (DocValuesBranch) for instance writes files per segment and field (using the field id within the file name). Yet, if a segment has no DocValues indexed in a particular segment but a previous segment in the same IW session had DocValues, FieldInfo#docValues will be true since those values are reused from previous segments. We already work around this limitation in SegmentInfo with properties like hasVectors or hasProx which is really something we should manage per Codec Segment. Ideally FieldInfo would be managed per Segment and Codec such that its properties are valid per segment. It also seems to be necessary to bind FieldInfoS to SegmentInfo logically since its really just per segment metadata. -- This message is automatically generated by JIRA. 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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6201 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6201/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-Solr-tests-only-3.x - Build # 6185 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6185/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6202 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6202/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterMergePolicy.testMaxBufferedDocsChange Error Message: null Stack Trace: junit.framework.AssertionFailedError: at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) at org.apache.lucene.index.TestIndexWriterMergePolicy.checkInvariants(TestIndexWriterMergePolicy.java:239) at org.apache.lucene.index.TestIndexWriterMergePolicy.testMaxBufferedDocsChange(TestIndexWriterMergePolicy.java:171) Build Log (for compile errors): [...truncated 3157 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-2973) Source distribution packaging targets should make a tarball from svn export
[
https://issues.apache.org/jira/browse/LUCENE-2973?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe resolved LUCENE-2973.
-
Resolution: Fixed
bq. The subversion {{export}} command has a {{--native-eol}} parameter
Solr's {{package-src}} and Lucene's {{dist-src}} targets should be made to use
this parameter with the {{LF}} arg, so that the source packages can be
consistently produced regardless of platform.
Committed:
- r1083945: trunk
- r1083946: branch_3x
- r1083947: lucene_solr_3_1
Source distribution packaging targets should make a tarball from svn export
-
Key: LUCENE-2973
URL: https://issues.apache.org/jira/browse/LUCENE-2973
Project: Lucene - Java
Issue Type: Improvement
Components: Build
Affects Versions: 3.1, 3.2, 4.0
Reporter: Steven Rowe
Assignee: Steven Rowe
Priority: Blocker
Fix For: 3.1, 3.2, 4.0
Attachments: LUCENE-2973.patch, LUCENE-2973.patch, LUCENE-2973.patch,
LUCENE-2973.patch, LUCENE-2973.patch, LUCENE-2973.patch, LUCENE-2973.patch
Instead of picking and choosing which stuff to include from a local working
copy, Lucene's dist-src/package-tgz-src target and Solr's package-src target
should simply perform svn export with the same revision and URL as the
local working copy.
--
This message is automatically generated by JIRA.
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
[HUDSON] Lucene-Solr-tests-only-3.x - Build # 6186 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6186/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[Lucene.Net] [jira] [Commented] (LUCENENET-405) Port: contrib/Analysis.NGram
[ https://issues.apache.org/jira/browse/LUCENENET-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009375#comment-13009375 ] Prescott Nasser commented on LUCENENET-405: --- Any objections to committing this? or was this uploaded as a patch and forgotten about? Port: contrib/Analysis.NGram Key: LUCENENET-405 URL: https://issues.apache.org/jira/browse/LUCENENET-405 Project: Lucene.Net Issue Type: New Feature Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4 Reporter: Digy Assignee: Digy Priority: Trivial Attachments: NGram.patch NGramTokenizer EdgeNGramTokenizer + Test cases. DIGY -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6203 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6203/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
Re: [Lucene.Net] Arithmetic Overflow
That's a good point. There are a lot of scenarios where exceptions could still occur, even with parameter validation. The difference is, in some situations, MaxInt/2 is a valid value. However, Int32.MaxValue is never a valid value due to the internal sorting logic requiring an additional array slot beyond the parameter value. Another example is any negative value. Negative values are always invalid for this parameter. The parameter values should be checked for known 'always invalid' conditions, and ArgumentException should be thrown explaining the problem. Thanks, Troy On Mon, Mar 21, 2011 at 12:58 PM, Digy digyd...@gmail.com wrote: Is -for ex- MaxInt/2 a valid value? You can get easily an OOM exception( and the worst case would be getting sporadic OOM when search fequency increases). DIGY -Original Message- From: Troy Howard [mailto:thowar...@gmail.com] Sent: Monday, March 21, 2011 9:43 PM To: lucene-net-...@lucene.apache.org Subject: Re: [Lucene.Net] Arithmetic Overflow I agree that it should not throw an overflow exception. That's not very helpful for debugging. The valid range of that parameter is essentially [0... Int32.MaxValue-1].. That's because it needs one extra slot in it's internal array, beyond the max size for juggling values during sort. The exception is thrown when it tries to setup the array to be the parameter value +1 to accommodate that... So the best we could do would be to throw a nicer exception when someone passes an invalid value. Until a nicer exception can be worked into the code, the documentation should be updated to reflect that limit... Thanks, Troy On Mon, Mar 21, 2011 at 12:15 PM, steven.h...@pattersoncompanies.com wrote: While I understand that and thank you for taking the time to respond, my concern was that passing a perfectly valid parameter leads to an exception. So this is bad design. Regards, Steve Hoff From: Digy digyd...@gmail.com To: lucene-net-...@lucene.apache.org Date: 03/21/2011 01:53 PM Subject: RE: [Lucene.Net] Arithmetic Overflow This is an expected behaviour. You get arithmetic overflow since an array[MaxInt] is created in PriorityQueue to store the results. (Lucene doesn't know the result-count before iterating over the results). If you want to collect all results( say,not the top 10 or 100), you can use HitCollector. DIGY -Original Message- From: steven.h...@pattersoncompanies.com [mailto:steven.h...@pattersoncompanies.com] Sent: Monday, March 21, 2011 7:10 PM To: lucene-net-...@lucene.apache.org Subject: RE: [Lucene.Net] Arithmetic Overflow I'm not sure how to report this or if this is working as intended, however using the recommended Search overload of IndexSearcher and passing Int32.MaxValue, results in an arithmetic overflow exception in PriorityQueue.Initialize(int maxSize). I tested this out on several platforms, including Windows 7 - 32, 64, Server 2003, Server 2008. Perhaps the parameter that is passed to the Search method should be updated to reflect a more realistic value? Regards, Steve Hoff NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer. NOTICE: This email transmission and any attachments that accompany it may contain information that is confidential or otherwise exempt from disclosure under applicable law and is intended solely for the use of the individual(s) to whom it was intended to be addressed. If you have received this email by mistake, or you are not the intended recipient, any disclosure, dissemination, distribution, copying or other use or retention of this communication or its substance is prohibited. If you have received this communication in error, please immediately report to the author via email that you received this message by mistake and also permanently destroy printed copies and delete the original and all copies of this email and any attachments from your computer.
[Lucene.Net] [jira] [Commented] (LUCENENET-405) Port: contrib/Analysis.NGram
[ https://issues.apache.org/jira/browse/LUCENENET-405?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009390#comment-13009390 ] Digy commented on LUCENENET-405: No. I just forgot to commit :) DIGY Port: contrib/Analysis.NGram Key: LUCENENET-405 URL: https://issues.apache.org/jira/browse/LUCENENET-405 Project: Lucene.Net Issue Type: New Feature Affects Versions: Lucene.Net 2.9.2, Lucene.Net 2.9.4 Reporter: Digy Assignee: Digy Priority: Trivial Attachments: NGram.patch NGramTokenizer EdgeNGramTokenizer + Test cases. DIGY -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[HUDSON] Lucene-Solr-tests-only-3.x - Build # 6187 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6187/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6204 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6204/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-Solr-tests-only-3.x - Build # 6188 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6188/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[Lucene.Net] [jira] [Commented] (LUCENENET-399) Port changes from Java Lucene 2.9.3 and 2.9.4 releases
[ https://issues.apache.org/jira/browse/LUCENENET-399?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009422#comment-13009422 ] Digy commented on LUCENENET-399: There are only a few minor remaining issues for Lucene.Net 2.9.4 core like changing visibility of IndexWriter.GetNextMerge or fixing TestNumericUtils.TestLongExtremeValues. It is almost ready. DIGY Port changes from Java Lucene 2.9.3 and 2.9.4 releases -- Key: LUCENENET-399 URL: https://issues.apache.org/jira/browse/LUCENENET-399 Project: Lucene.Net Issue Type: Task Components: Lucene.Net Core, Lucene.Net Test Reporter: Troy Howard Assignee: Scott Lombard Fix For: Lucene.Net 2.9.4 Time Spent: 10h Remaining Estimate: 10h Port changes from Java Lucene 2.9.3 and 2.9.4 releases. The Lucene.Net 2.9.4 release will roll up the changes from both of those releases into one. Unit tests should be added or updated to reflect the changes. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6205 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6205/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-Solr-tests-only-3.x - Build # 6189 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6189/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6206 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6206/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-Solr-tests-only-3.x - Build # 6190 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6190/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6207 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6207/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-3.x - Build # 321 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-3.x/321/ All tests passed Build Log (for compile errors): [...truncated 18976 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-3.x - Build # 6191 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6191/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6208 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6208/ 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterMergePolicy.testMaxBufferedDocsChange Error Message: null Stack Trace: junit.framework.AssertionFailedError: at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) at org.apache.lucene.index.TestIndexWriterMergePolicy.checkInvariants(TestIndexWriterMergePolicy.java:239) at org.apache.lucene.index.TestIndexWriterMergePolicy.testMaxBufferedDocsChange(TestIndexWriterMergePolicy.java:171) Build Log (for compile errors): [...truncated 3158 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-Solr-tests-only-3.x - Build # 6192 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6192/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[jira] [Assigned] (SOLR-2061) Generate jar containing test classes.
[ https://issues.apache.org/jira/browse/SOLR-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir reassigned SOLR-2061: - Assignee: Robert Muir Generate jar containing test classes. - Key: SOLR-2061 URL: https://issues.apache.org/jira/browse/SOLR-2061 Project: Solr Issue Type: Improvement Components: Build Affects Versions: 3.1 Reporter: Drew Farris Assignee: Robert Muir Priority: Minor Fix For: 3.2, 4.0 Attachments: SOLR-2061.patch, SOLR-2061.patch Follow-on to LUCENE-2609 for the solr build -- it would be useful to generate and deploy a jar contaiing the test classes so other projects could write unit tests using the framework in Solr. This may take care of SOLR-717 as well. -- This message is automatically generated by JIRA. 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-2061) Generate jar containing test classes.
[ https://issues.apache.org/jira/browse/SOLR-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-2061: -- Fix Version/s: 4.0 3.2 Generate jar containing test classes. - Key: SOLR-2061 URL: https://issues.apache.org/jira/browse/SOLR-2061 Project: Solr Issue Type: Improvement Components: Build Affects Versions: 3.1 Reporter: Drew Farris Assignee: Robert Muir Priority: Minor Fix For: 3.2, 4.0 Attachments: SOLR-2061.patch, SOLR-2061.patch Follow-on to LUCENE-2609 for the solr build -- it would be useful to generate and deploy a jar contaiing the test classes so other projects could write unit tests using the framework in Solr. This may take care of SOLR-717 as well. -- This message is automatically generated by JIRA. 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-2061) Generate jar containing test classes.
[
https://issues.apache.org/jira/browse/SOLR-2061?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated SOLR-2061:
--
Attachment: SOLR-2061.patch
attached is a patch that makes a test-framework like lucene's.
The solr contribs now only depend on this, not all the concrete tests.
This makes it easy for someone developing a plugin to put schema.xml/etc in
their test classpath, extend SolrTestCaseJ4, etc.
Before applying the patch, please do this:
{noformat}
svn mkdir solr/src/test-framework
svn mv --parents
solr/src/test/org/apache/solr/BaseDistributedSearchTestCase.java
solr/src/test-framework/org/apache/solr/BaseDistributedSearchTestCase.java
svn mv --parents solr/src/test/org/apache/solr/JSONTestUtil.java
solr/src/test-framework/org/apache/solr/JSONTestUtil.java
svn mv --parents solr/src/test/org/apache/solr/SolrTestCaseJ4.java
solr/src/test-framework/org/apache/solr/SolrTestCaseJ4.java
svn mv --parents solr/src/test/org/apache/solr/analysis/BaseTokenTestCase.java
solr/src/test-framework/org/apache/solr/analysis/BaseTokenTestCase.java
svn mv --parents solr/src/test/org/apache/solr/util/AbstractSolrTestCase.java
solr/src/test-framework/org/apache/solr/util/AbstractSolrTestCase.java
svn mv --parents solr/src/java/org/apache/solr/util/TestHarness.java
solr/src/test-framework/org/apache/solr/util/TestHarness.java
{noformat}
Generate jar containing test classes.
-
Key: SOLR-2061
URL: https://issues.apache.org/jira/browse/SOLR-2061
Project: Solr
Issue Type: Improvement
Components: Build
Affects Versions: 3.1
Reporter: Drew Farris
Assignee: Robert Muir
Priority: Minor
Fix For: 3.2, 4.0
Attachments: SOLR-2061.patch, SOLR-2061.patch, SOLR-2061.patch
Follow-on to LUCENE-2609 for the solr build -- it would be useful to generate
and deploy a jar contaiing the test classes so other projects could write
unit tests using the framework in Solr.
This may take care of SOLR-717 as well.
--
This message is automatically generated by JIRA.
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
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6209 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6209/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-Solr-tests-only-3.x - Build # 6193 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6193/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-Solr-tests-only-trunk - Build # 6210 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-trunk/6210/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:127) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1214) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1146) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[HUDSON] Lucene-Solr-tests-only-3.x - Build # 6194 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-Solr-tests-only-3.x/6194/ 2 tests failed. FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testProcessing(UIMAUpdateRequestProcessorTest.java:76) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.processUntilNextOutputCas(ASB_impl.java:567) at org.apache.uima.analysis_engine.asb.impl.ASB_impl$AggregateCasIterator.init(ASB_impl.java:409) at org.apache.uima.analysis_engine.asb.impl.ASB_impl.process(ASB_impl.java:342) at org.apache.uima.analysis_engine.impl.AggregateAnalysisEngine_impl.processAndOutputNewCASes(AggregateAnalysisEngine_impl.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:267) at org.apache.uima.analysis_engine.impl.AnalysisEngineImplBase.process(AnalysisEngineImplBase.java:280) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processText(UIMAUpdateRequestProcessor.java:122) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:69) Caused by: org.apache.uima.alchemy.digester.exception.ResultDigestingException: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:133) Caused by: org.apache.uima.alchemy.annotator.exception.AlchemyCallFailedException: ERROR at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:129) FAILED: org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates Error Message: org.apache.uima.analysis_engine.AnalysisEngineProcessException Stack Trace: java.lang.RuntimeException: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.solr.uima.processor.UIMAUpdateRequestProcessor.processAdd(UIMAUpdateRequestProcessor.java:82) at org.apache.solr.handler.XMLLoader.processUpdate(XMLLoader.java:147) at org.apache.solr.handler.XMLLoader.load(XMLLoader.java:77) at org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:55) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.addDoc(UIMAUpdateRequestProcessorTest.java:120) at org.apache.solr.uima.processor.UIMAUpdateRequestProcessorTest.testTwoUpdates(UIMAUpdateRequestProcessorTest.java:94) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1075) at org.apache.lucene.util.LuceneTestCase$LuceneTestCaseRunner.runChild(LuceneTestCase.java:1007) Caused by: org.apache.uima.analysis_engine.AnalysisEngineProcessException at org.apache.uima.alchemy.annotator.AbstractAlchemyAnnotator.process(AbstractAlchemyAnnotator.java:138) at org.apache.uima.analysis_component.JCasAnnotator_ImplBase.process(JCasAnnotator_ImplBase.java:48) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.callAnalysisComponentProcess(PrimitiveAnalysisEngine_impl.java:377) at org.apache.uima.analysis_engine.impl.PrimitiveAnalysisEngine_impl.processAndOutputNewCASes(PrimitiveAnalysisEngine_impl.java:295) at
[jira] [Created] (SOLR-2437) Use IndexWriter.deleteAll() in DUH2.deleteAll() instead of closing and reopening writer w/ create=true
Use IndexWriter.deleteAll() in DUH2.deleteAll() instead of closing and reopening writer w/ create=true --- Key: SOLR-2437 URL: https://issues.apache.org/jira/browse/SOLR-2437 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Koji Sekiguchi Priority: Minor Use just IW.deleteAll() to abort background merges, remove buffered docs, etc. -- This message is automatically generated by JIRA. 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-2437) Use IndexWriter.deleteAll() in DUH2.deleteAll() instead of closing and reopening writer w/ create=true
[ https://issues.apache.org/jira/browse/SOLR-2437?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Koji Sekiguchi updated SOLR-2437: - Attachment: SOLR-2437.patch Use IndexWriter.deleteAll() in DUH2.deleteAll() instead of closing and reopening writer w/ create=true --- Key: SOLR-2437 URL: https://issues.apache.org/jira/browse/SOLR-2437 Project: Solr Issue Type: Improvement Affects Versions: 1.4 Reporter: Koji Sekiguchi Priority: Minor Attachments: SOLR-2437.patch Use just IW.deleteAll() to abort background merges, remove buffered docs, etc. -- This message is automatically generated by JIRA. 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-2387) UIMA tests are unstable
[ https://issues.apache.org/jira/browse/SOLR-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved SOLR-2387. --- Resolution: Fixed Fix Version/s: 4.0 Committed revision 1084045. (trunk) Committed revision 1084047. (branch_3x) UIMA tests are unstable --- Key: SOLR-2387 URL: https://issues.apache.org/jira/browse/SOLR-2387 Project: Solr Issue Type: Bug Reporter: Robert Muir Assignee: Robert Muir Fix For: 3.2, 4.0 Attachments: SOLR2387.patch, SOLR2387_2.patch, SOLR2387_2b.patch The UIMA tests fail frequently in hudson now. I am not sure if this is due to not being able to connect to specific sites, but if this is the case it would be better to use a Mock component instead that doesn't need to do this. -- This message is automatically generated by JIRA. 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-2387) UIMA tests are unstable
[ https://issues.apache.org/jira/browse/SOLR-2387?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009504#comment-13009504 ] Robert Muir commented on SOLR-2387: --- Tommaso, thanks again! UIMA tests are unstable --- Key: SOLR-2387 URL: https://issues.apache.org/jira/browse/SOLR-2387 Project: Solr Issue Type: Bug Reporter: Robert Muir Assignee: Robert Muir Fix For: 3.2, 4.0 Attachments: SOLR2387.patch, SOLR2387_2.patch, SOLR2387_2b.patch The UIMA tests fail frequently in hudson now. I am not sure if this is due to not being able to connect to specific sites, but if this is the case it would be better to use a Mock component instead that doesn't need to do this. -- This message is automatically generated by JIRA. 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-2396) add [ICU]CollationField
[ https://issues.apache.org/jira/browse/SOLR-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-2396: -- Description: In LUCENE-2551 collation support was changed to use byte[] keys. Previously it encoded sort keys with IndexableBinaryString into char[], but this is wasteful with regards to RAM and disk when terms can be byte. A better solution would be [ICU]CollationFieldTypes, as this would also allow locale-sensitive range queries. was: In LUCENE-2551 collation support was changed to use byte[] keys. Previously it encoded sort keys with IndexableBinaryString into char[], but this is wasteful with regards to RAM and disk when terms can be byte. A simple solution is to create tokenizer factories which are KeywordTokenizer + [ICU]CollationAttributeFactory. A better solution would be [ICU]CollationFieldTypes, as this would allow locale-sensitive range queries, but I found this to be more difficult due to the fact that the indexed values are byte[] not String... Summary: add [ICU]CollationField (was: deprecated char[] based collation factories / replace with byte[]-based) editing summary/description to fit add [ICU]CollationField --- Key: SOLR-2396 URL: https://issues.apache.org/jira/browse/SOLR-2396 Project: Solr Issue Type: Improvement Reporter: Robert Muir Fix For: 4.0 Attachments: SOLR-2396.patch, SOLR-2396.patch, SOLR-2396.patch In LUCENE-2551 collation support was changed to use byte[] keys. Previously it encoded sort keys with IndexableBinaryString into char[], but this is wasteful with regards to RAM and disk when terms can be byte. A better solution would be [ICU]CollationFieldTypes, as this would also allow locale-sensitive range queries. -- This message is automatically generated by JIRA. 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-2396) add [ICU]CollationField
[ https://issues.apache.org/jira/browse/SOLR-2396?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-2396: -- Attachment: SOLR-2396.patch now that the lucene issues are resolved, I think this patch is really close. It could use a review though from someone who knows the fieldtype stuff better. add [ICU]CollationField --- Key: SOLR-2396 URL: https://issues.apache.org/jira/browse/SOLR-2396 Project: Solr Issue Type: Improvement Reporter: Robert Muir Fix For: 4.0 Attachments: SOLR-2396.patch, SOLR-2396.patch, SOLR-2396.patch, SOLR-2396.patch In LUCENE-2551 collation support was changed to use byte[] keys. Previously it encoded sort keys with IndexableBinaryString into char[], but this is wasteful with regards to RAM and disk when terms can be byte. A better solution would be [ICU]CollationFieldTypes, as this would also allow locale-sensitive range queries. -- This message is automatically generated by JIRA. 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-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adriano Crestani updated LUCENE-1768: - Labels: contrib gsoc lucene-gsoc-11 (was: ) NumericRange support for new query parser - Key: LUCENE-1768 URL: https://issues.apache.org/jira/browse/LUCENE-1768 Project: Lucene - Java Issue Type: New Feature Components: QueryParser Affects Versions: 2.9 Reporter: Uwe Schindler Assignee: Uwe Schindler Labels: contrib, gsoc, lucene-gsoc-11 Fix For: 4.0 It would be good to specify some type of schema for the query parser in future, to automatically create NumericRangeQuery for different numeric types? It would then be possible to index a numeric value (double,float,long,int) using NumericField and then the query parser knows, which type of field this is and so it correctly creates a NumericRangeQuery for strings like [1.567..*] or (1.787..19.5]. There is currently no way to extract if a field is numeric from the index, so the user will have to configure the FieldConfig objects in the ConfigHandler. But if this is done, it will not be that difficult to implement the rest. The only difference between the current handling of RangeQuery is then the instantiation of the correct Query type and conversion of the entered numeric values (simple Number.valueOf(...) cast of the user entered numbers). Evenerything else is identical, NumericRangeQuery also supports the MTQ rewrite modes (as it is a MTQ). Another thing is a change in Date semantics. There are some strange flags in the current parser that tells it how to handle dates. -- This message is automatically generated by JIRA. 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-1768) NumericRange support for new query parser
[ https://issues.apache.org/jira/browse/LUCENE-1768?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13009522#comment-13009522 ] Adriano Crestani commented on LUCENE-1768: -- I think this is also a good candidate for GSoC 2011. I will add the labels to it. Any comments? NumericRange support for new query parser - Key: LUCENE-1768 URL: https://issues.apache.org/jira/browse/LUCENE-1768 Project: Lucene - Java Issue Type: New Feature Components: QueryParser Affects Versions: 2.9 Reporter: Uwe Schindler Assignee: Uwe Schindler Labels: contrib, gsoc, lucene-gsoc-11 Fix For: 4.0 It would be good to specify some type of schema for the query parser in future, to automatically create NumericRangeQuery for different numeric types? It would then be possible to index a numeric value (double,float,long,int) using NumericField and then the query parser knows, which type of field this is and so it correctly creates a NumericRangeQuery for strings like [1.567..*] or (1.787..19.5]. There is currently no way to extract if a field is numeric from the index, so the user will have to configure the FieldConfig objects in the ConfigHandler. But if this is done, it will not be that difficult to implement the rest. The only difference between the current handling of RangeQuery is then the instantiation of the correct Query type and conversion of the entered numeric values (simple Number.valueOf(...) cast of the user entered numbers). Evenerything else is identical, NumericRangeQuery also supports the MTQ rewrite modes (as it is a MTQ). Another thing is a change in Date semantics. There are some strange flags in the current parser that tells it how to handle dates. -- This message is automatically generated by JIRA. For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Urgent! Forgot to close IndexWriter after adding Documents to the index.
(replying to the dev list, see context below) : Unfortunately, you can't easily recover from this (except by : reindexing your docs again). : : Failing to call IW.commit() or IW.close() means no segments file was written... I know there were good reasons for eliminating the autoCommit functionality from IndexWriter, but threads like tis make me thing thta even though autoCommit on flush/merge/whatever was bad, having an option for some sort of autoClose using a finalizer might by a good idea to give new/novice users a safety net. In the case of totally successful normal operation, this would result in one commit at GC (assuming the JVM calls the finalizer) and if there were any errors it should (if i understnad correclty) do an implicit rollback. Anyone see a downside? ... : I had a program running for 2 days to build an index for around 160 million : text files, and after program ended, I tried searching the index and found : the index was not correctly built, *indexReader.numDocs()* returns 0. I : checked the index directory, it looked good, all the index data seemed to be : there, the directory is 1.5 Gigabytes in size. : : I checked my code and found that I forgot to call *indexWriter.optimize()*and : *indexWriter.close()*, I want to know if it is possible to : *re-optimize()*the index so I don't need to rebuild the whole index : from scratch? I don't : really want the program to take another 2 days. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[HUDSON] Lucene-trunk - Build # 1504 - Still Failing
Build: https://hudson.apache.org/hudson/job/Lucene-trunk/1504/ All tests passed Build Log (for compile errors): [...truncated 16607 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
