Using JCC from pure C++, patches
Hi!
I've been using JCC to interact with Java code from C++ for a few weeks now.
(no python involved)
It's been working well, but I've had to patch the C++ code in sources/ a
little. I thought I'd share the patches; hopefully at least some of them can
make it into mainline JCC. I pulled the source from
http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/jcc/sources/ this
morning, so I hope that the files should be up to date.
===
First, in JArray.h there was a missing typedef when not using python:
--- JArray.h.02013-02-05 10:49:05.650684100 +0100
+++ JArray.h.1 2013-02-05 10:49:40.901160300 +0100
@@ -37,6 +37,8 @@
extern PyTypeObject *PY_TYPE(JArrayLong);
extern PyTypeObject *PY_TYPE(JArrayShort);
+#else
+typedef int Py_ssize_t;
#endif
#include JCCEnv.h
=
There was a missing #include in JCCEnv.cpp (free, realloc, and calloc were not
found):
--- JCCEnv.cpp.0 2013-02-05 10:49:22.497323300 +0100
+++ JCCEnv.cpp.1 2013-02-05 10:49:48.613639700 +0100
@@ -13,6 +13,7 @@
*/
#include map
+#include stdlib.h
#include string.h
#include jni.h
I got a slew of warnings for non-const char pointers initialized with string
literals, this patch seems to fix it (created on top of the last patch):
--- JCCEnv.cpp.1 2013-02-05 10:49:48.613639700 +0100
+++ JCCEnv.cpp.2 2013-02-05 10:52:20.451420600 +0100
@@ -818,10 +818,10 @@
jmethodID mu = vm_env-GetMethodID(_fil, toURL, ()Ljava/net/URL;);
jmethodID ma = vm_env-GetMethodID(_ucl, addURL, (Ljava/net/URL;)V);
#if defined(_MSC_VER) || defined(__WIN32)
-char *pathsep = ;;
+const char *pathsep = ;;
char *path = _strdup(classPath);
#else
-char *pathsep = :;
+const char *pathsep = :;
char *path = strdup(classPath);
#endif
@@ -848,9 +848,9 @@
jmethodID gu = vm_env-GetMethodID(_ucl, getURLs, ()[Ljava/net/URL;);
jmethodID gp = vm_env-GetMethodID(_url, getPath,
()Ljava/lang/String;);
#if defined(_MSC_VER) || defined(__WIN32)
-char *pathsep = ;;
+const char *pathsep = ;;
#else
-char *pathsep = :;
+const char *pathsep = :;
#endif
jobjectArray array = (jobjectArray)
vm_env-CallObjectMethod(classLoader, gu);
Lastly, I got some pretty nasty crashes when I failed to supply a proper
classpath to the JVM. The following patch to JCCEnv.cpp (built on top of the
previous one) exits with an error instead. You might want to handle the error
in another way, but I do think that there is a value in catching it:
--- JCCEnv.cpp.2 2013-02-05 10:52:20.451420600 +0100
+++ JCCEnv.cpp.3 2013-02-05 11:00:24.911939300 +0100
@@ -15,6 +15,7 @@
#include map
#include stdlib.h
#include string.h
+#include iostream
#include jni.h
#include JCCEnv.h
@@ -259,8 +260,13 @@
{
JNIEnv *vm_env = get_vm_env();
-if (vm_env)
+if (vm_env) {
cls = vm_env-FindClass(className);
+ if (cls == NULL) {
+std::cerr Could not
find class className std::endl;
+exit(1);
+ }
+ }
#ifdef PYTHON
else
{
Best,
Toivo Henningsson, PhD
Senior Software Engineer
Simulation Optimization Technology
Phone direct: +46 46 286 22 11
Email: toivo.hennings...@modelon.commailto:toivo.hennings...@modelon.com
[Description: Description: Modelon_2011_Gradient_RGB_400]
Modelon AB
Ideon Science Park
SE-223 70 Lund, Sweden
Phone: +46 46 286 2200
Fax: +46 46 286 2201
Web: http://www.modelon.comhttp://www.modelon.com/
This email and any attachments are intended solely for the use of the
individual or entity to whom it is addressed and may be confidential and/or
privileged. If you are not one of the named recipients or have received this
email in error, (i) you should not read, disclose, or copy it, (ii) please
notify sender of your receipt by reply email and delete this email and all
attachments, (iii) Modelon does not accept or assume any liability or
responsibility for any use of or reliance on this email.
Re: Using JCC from pure C++, patches
Nice to see that there are users using only the C++ side of things !
Thank you for your patches, I integrated them into rev 1442731.
Some comments inline below.
On Tue, 5 Feb 2013, Toivo Henningsson wrote:
Hi!
I've been using JCC to interact with Java code from C++ for a few weeks now.
(no python involved)
It's been working well, but I've had to patch the C++ code in sources/ a
little. I thought I'd share the patches; hopefully at least some of them can
make it into mainline JCC. I pulled the source from
http://svn.apache.org/repos/asf/lucene/pylucene/trunk/jcc/jcc/sources/ this
morning, so I hope that the files should be up to date.
===
First, in JArray.h there was a missing typedef when not using python:
--- JArray.h.02013-02-05 10:49:05.650684100 +0100
+++ JArray.h.1 2013-02-05 10:49:40.901160300 +0100
@@ -37,6 +37,8 @@
extern PyTypeObject *PY_TYPE(JArrayLong);
extern PyTypeObject *PY_TYPE(JArrayShort);
+#else
+typedef int Py_ssize_t;
#endif
#include JCCEnv.h
Integrated as is.
=
There was a missing #include in JCCEnv.cpp (free, realloc, and calloc were not
found):
--- JCCEnv.cpp.0 2013-02-05 10:49:22.497323300 +0100
+++ JCCEnv.cpp.1 2013-02-05 10:49:48.613639700 +0100
@@ -13,6 +13,7 @@
*/
#include map
+#include stdlib.h
#include string.h
#include jni.h
Same.
I got a slew of warnings for non-const char pointers initialized with string
literals, this patch seems to fix it (created on top of the last patch):
--- JCCEnv.cpp.1 2013-02-05 10:49:48.613639700 +0100
+++ JCCEnv.cpp.2 2013-02-05 10:52:20.451420600 +0100
@@ -818,10 +818,10 @@
jmethodID mu = vm_env-GetMethodID(_fil, toURL, ()Ljava/net/URL;);
jmethodID ma = vm_env-GetMethodID(_ucl, addURL, (Ljava/net/URL;)V);
#if defined(_MSC_VER) || defined(__WIN32)
-char *pathsep = ;;
+const char *pathsep = ;;
char *path = _strdup(classPath);
#else
-char *pathsep = :;
+const char *pathsep = :;
char *path = strdup(classPath);
#endif
@@ -848,9 +848,9 @@
jmethodID gu = vm_env-GetMethodID(_ucl, getURLs, ()[Ljava/net/URL;);
jmethodID gp = vm_env-GetMethodID(_url, getPath, ()Ljava/lang/String;);
#if defined(_MSC_VER) || defined(__WIN32)
-char *pathsep = ;;
+const char *pathsep = ;;
#else
-char *pathsep = :;
+const char *pathsep = :;
#endif
jobjectArray array = (jobjectArray)
vm_env-CallObjectMethod(classLoader, gu);
Same.
Lastly, I got some pretty nasty crashes when I failed to supply a proper
classpath to the JVM. The following patch to JCCEnv.cpp (built on top of the
previous one) exits with an error instead. You might want to handle the error
in another way, but I do think that there is a value in catching it:
--- JCCEnv.cpp.2 2013-02-05 10:52:20.451420600 +0100
+++ JCCEnv.cpp.3 2013-02-05 11:00:24.911939300 +0100
@@ -15,6 +15,7 @@
#include map
#include stdlib.h
#include string.h
+#include iostream
#include jni.h
#include JCCEnv.h
@@ -259,8 +260,13 @@
{
JNIEnv *vm_env = get_vm_env();
-if (vm_env)
+if (vm_env) {
cls = vm_env-FindClass(className);
+ if (cls == NULL) {
+std::cerr Could not find class
className std::endl;
+exit(1);
+ }
+ }
#ifdef PYTHON
else
{
Here, I used the JCCEnv::reportException() method instead. It prints out a
valib Java stacktrace if there are no exception handlers and throws a C++
exception.
Best,
Andi..
Best,
Toivo Henningsson, PhD
Senior Software Engineer
Simulation Optimization Technology
Phone direct: +46 46 286 22 11
Email: toivo.hennings...@modelon.commailto:toivo.hennings...@modelon.com
[Description: Description: Modelon_2011_Gradient_RGB_400]
Modelon AB
Ideon Science Park
SE-223 70 Lund, Sweden
Phone: +46 46 286 2200
Fax: +46 46 286 2201
Web: http://www.modelon.comhttp://www.modelon.com/
This email and any attachments are intended solely for the use of the
individual or entity to whom it is addressed and may be confidential and/or
privileged. If you are not one of the named recipients or have received this
email in error, (i) you should not read, disclose, or copy it, (ii) please
notify sender of your receipt by reply email and delete this email and all
attachments, (iii) Modelon does not accept or assume any liability or
responsibility for any use of or reliance on this email.
[jira] [Resolved] (LUCENE-4751) IndexReader close throwing NullPointerException
[ https://issues.apache.org/jira/browse/LUCENE-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer resolved LUCENE-4751. - Resolution: Won't Fix The problem here is that you are getting this critical TooManyOpenFilesException which already brings down your site. You should raise the open files limit and I recommend you to upgrade to a newer lucene version. 2.9.2 is pretty old. IndexReader close throwing NullPointerException --- Key: LUCENE-4751 URL: https://issues.apache.org/jira/browse/LUCENE-4751 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 2.9.2 Environment: RedHat Reporter: Anusha Rao Hi, Has anyone seen the NullPointerException as shown below before? We have used Lucene to build a public site search functionality. All the IndexReader objects in there are closed appropriately except one that throws the following error and results in (too many files open) exception. This brings the entire site down. The lucene version we are using is lucene-core-2.9.2.jar Any idea what could cause this exception? java.lang.NullPointerException at org.apache.lucene.index.SegmentReader$Norm.decRef(SegmentReader.java:393) at org.apache.lucene.index.SegmentReader.doClose(SegmentReader.java:868) at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:170) at org.apache.lucene.index.DirectoryReader.doClose(DirectoryReader.java:803) at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:170) at org.apache.lucene.index.IndexReader.close(IndexReader.java:1302) at search.Searcher.search(Searcher.java:387) // the close in this class does not execute -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4358) SolrJ, by preventing multi-part post, loses key information about file name that Tika needs
[ https://issues.apache.org/jira/browse/SOLR-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated SOLR-4358: -- Attachment: SOLR-4358.patch Here's a patch that does essentially what I think is wanted. SolrJ, by preventing multi-part post, loses key information about file name that Tika needs --- Key: SOLR-4358 URL: https://issues.apache.org/jira/browse/SOLR-4358 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.0 Reporter: Karl Wright Attachments: SOLR-4358.patch SolrJ accepts a ContentStream, which has a name field. Within HttpSolrServer.java, if SolrJ makes the decision to use multipart posts, this filename is transmitted as part of the form boundary information. However, if SolrJ chooses not to use multipart post, the filename information is lost. This information is used by SolrCell (Tika) to make decisions about content extraction, so it is very important that it makes it into Solr in one way or another. Either SolrJ should set appropriate equivalent headers to send the filename automatically, or it should force multipart posts when this information is present. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4744) Attempt to get rid of FieldCache.StopFillCacheException
[ https://issues.apache.org/jira/browse/LUCENE-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571146#comment-13571146 ] Commit Tag Bot commented on LUCENE-4744: [trunk commit] Simon Willnauer http://svn.apache.org/viewvc?view=revisionrevision=1442497 LUCENE-4744: Remove FieldCache.StopFillChacheException Attempt to get rid of FieldCache.StopFillCacheException --- Key: LUCENE-4744 URL: https://issues.apache.org/jira/browse/LUCENE-4744 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.1 Reporter: Simon Willnauer Assignee: Simon Willnauer Priority: Minor Fix For: 4.2, 5.0 Attachments: LUCENE-4744.patch, LUCENE-4744.patch FieldCache.StopFillCacheException bugged me for a while and I think its a pretty hacky way to make our FC work with prefix coded terms. I think we should try to get rid of it... I will attach a patch soon. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4390) SolrJ does not URL-encode query string argument names but should
[ https://issues.apache.org/jira/browse/SOLR-4390?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Karl Wright updated SOLR-4390: -- Attachment: SOLR-4390.patch Here's the naive patch, which does not concern itself at all with backwards compatibility. If Mr. Hatcher is correct, and nobody uses SolrJ field names that are other than standard URL characters, this patch should suffice. But if anyone wants a more nuanced approach, let me know and I will create parameters that have knowledge of whether or not they need encoding at the SolrJ level. SolrJ does not URL-encode query string argument names but should Key: SOLR-4390 URL: https://issues.apache.org/jira/browse/SOLR-4390 Project: Solr Issue Type: Bug Components: clients - java Affects Versions: 4.1 Reporter: Karl Wright Attachments: SOLR-4390.patch SolrJ does not appear to URL-encode any metadata names, but should. This leads to URLs that are illegal, and thus an IllegalArgumentException gets thrown. See CONNECTORS-630 for an example of a bad URL that SolrJ generates. I understand that this may have been broken for a long time and that now backwards-compatibility is an issue, but it should still be possible to tell SolrJ to do the right thing and not make the SolrJ user do it. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4744) Attempt to get rid of FieldCache.StopFillCacheException
[ https://issues.apache.org/jira/browse/LUCENE-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer resolved LUCENE-4744. - Resolution: Fixed Attempt to get rid of FieldCache.StopFillCacheException --- Key: LUCENE-4744 URL: https://issues.apache.org/jira/browse/LUCENE-4744 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.1 Reporter: Simon Willnauer Assignee: Simon Willnauer Priority: Minor Fix For: 4.2, 5.0 Attachments: LUCENE-4744.patch, LUCENE-4744.patch FieldCache.StopFillCacheException bugged me for a while and I think its a pretty hacky way to make our FC work with prefix coded terms. I think we should try to get rid of it... I will attach a patch soon. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4744) Attempt to get rid of FieldCache.StopFillCacheException
[ https://issues.apache.org/jira/browse/LUCENE-4744?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571155#comment-13571155 ] Commit Tag Bot commented on LUCENE-4744: [branch_4x commit] Simon Willnauer http://svn.apache.org/viewvc?view=revisionrevision=1442499 LUCENE-4744: Remove FieldCache.StopFillChacheException Attempt to get rid of FieldCache.StopFillCacheException --- Key: LUCENE-4744 URL: https://issues.apache.org/jira/browse/LUCENE-4744 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 4.1 Reporter: Simon Willnauer Assignee: Simon Willnauer Priority: Minor Fix For: 4.2, 5.0 Attachments: LUCENE-4744.patch, LUCENE-4744.patch FieldCache.StopFillCacheException bugged me for a while and I think its a pretty hacky way to make our FC work with prefix coded terms. I think we should try to get rid of it... I will attach a patch soon. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4570) release policeman tools?
[ https://issues.apache.org/jira/browse/LUCENE-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571171#comment-13571171 ] Commit Tag Bot commented on LUCENE-4570: [trunk commit] Uwe Schindler http://svn.apache.org/viewvc?view=revisionrevision=1442508 LUCENE-4570: typo release policeman tools? Key: LUCENE-4570 URL: https://issues.apache.org/jira/browse/LUCENE-4570 Project: Lucene - Core Issue Type: New Feature Reporter: Robert Muir Assignee: Uwe Schindler Attachments: LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch Currently there is source code in lucene/tools/src (e.g. Forbidden APIs checker ant task). It would be convenient if you could download this thing in your ant build from ivy (especially if maybe it included our definitions .txt files as resources). In general checking for locale/charset violations in this way is a pretty general useful thing for a server-side app. Can we either release lucene-tools.jar as an artifact, or maybe alternatively move this somewhere else as a standalone project and suck it in ourselves? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4570) release policeman tools?
[ https://issues.apache.org/jira/browse/LUCENE-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571172#comment-13571172 ] Commit Tag Bot commented on LUCENE-4570: [trunk commit] Uwe Schindler http://svn.apache.org/viewvc?view=revisionrevision=1442507 LUCENE-4570: Use the Policeman Formbidden API checker, released separately from Lucene and downloaded via Ivy release policeman tools? Key: LUCENE-4570 URL: https://issues.apache.org/jira/browse/LUCENE-4570 Project: Lucene - Core Issue Type: New Feature Reporter: Robert Muir Assignee: Uwe Schindler Attachments: LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch Currently there is source code in lucene/tools/src (e.g. Forbidden APIs checker ant task). It would be convenient if you could download this thing in your ant build from ivy (especially if maybe it included our definitions .txt files as resources). In general checking for locale/charset violations in this way is a pretty general useful thing for a server-side app. Can we either release lucene-tools.jar as an artifact, or maybe alternatively move this somewhere else as a standalone project and suck it in ourselves? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4570) release policeman tools?
[ https://issues.apache.org/jira/browse/LUCENE-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571180#comment-13571180 ] Uwe Schindler commented on LUCENE-4570: --- I committed the attached patch to trunk and 4.x. I am now working on completing the documentation on the Google Code page: http://code.google.com/p/forbidden-apis/ Thanks to the default locale/charset/timezone ghostbuster! :-) release policeman tools? Key: LUCENE-4570 URL: https://issues.apache.org/jira/browse/LUCENE-4570 Project: Lucene - Core Issue Type: New Feature Reporter: Robert Muir Assignee: Uwe Schindler Attachments: LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch Currently there is source code in lucene/tools/src (e.g. Forbidden APIs checker ant task). It would be convenient if you could download this thing in your ant build from ivy (especially if maybe it included our definitions .txt files as resources). In general checking for locale/charset violations in this way is a pretty general useful thing for a server-side app. Can we either release lucene-tools.jar as an artifact, or maybe alternatively move this somewhere else as a standalone project and suck it in ourselves? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4570) release policeman tools?
[ https://issues.apache.org/jira/browse/LUCENE-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-4570. --- Resolution: Fixed Fix Version/s: 5.0 4.2 release policeman tools? Key: LUCENE-4570 URL: https://issues.apache.org/jira/browse/LUCENE-4570 Project: Lucene - Core Issue Type: New Feature Reporter: Robert Muir Assignee: Uwe Schindler Fix For: 4.2, 5.0 Attachments: LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch Currently there is source code in lucene/tools/src (e.g. Forbidden APIs checker ant task). It would be convenient if you could download this thing in your ant build from ivy (especially if maybe it included our definitions .txt files as resources). In general checking for locale/charset violations in this way is a pretty general useful thing for a server-side app. Can we either release lucene-tools.jar as an artifact, or maybe alternatively move this somewhere else as a standalone project and suck it in ourselves? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4570) Release ForbiddenAPI checker on Google Code
[ https://issues.apache.org/jira/browse/LUCENE-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4570: -- Summary: Release ForbiddenAPI checker on Google Code (was: release policeman tools?) Release ForbiddenAPI checker on Google Code --- Key: LUCENE-4570 URL: https://issues.apache.org/jira/browse/LUCENE-4570 Project: Lucene - Core Issue Type: New Feature Reporter: Robert Muir Assignee: Uwe Schindler Fix For: 4.2, 5.0 Attachments: LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch Currently there is source code in lucene/tools/src (e.g. Forbidden APIs checker ant task). It would be convenient if you could download this thing in your ant build from ivy (especially if maybe it included our definitions .txt files as resources). In general checking for locale/charset violations in this way is a pretty general useful thing for a server-side app. Can we either release lucene-tools.jar as an artifact, or maybe alternatively move this somewhere else as a standalone project and suck it in ourselves? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4570) Release ForbiddenAPI checker on Google Code
[ https://issues.apache.org/jira/browse/LUCENE-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571182#comment-13571182 ] Commit Tag Bot commented on LUCENE-4570: [branch_4x commit] Uwe Schindler http://svn.apache.org/viewvc?view=revisionrevision=1442509 Merged revision(s) 1442507-1442508 from lucene/dev/trunk: LUCENE-4570: Use the Policeman Forbidden API checker, released separately from Lucene and downloaded via Ivy LUCENE-4570: typo Release ForbiddenAPI checker on Google Code --- Key: LUCENE-4570 URL: https://issues.apache.org/jira/browse/LUCENE-4570 Project: Lucene - Core Issue Type: New Feature Reporter: Robert Muir Assignee: Uwe Schindler Fix For: 4.2, 5.0 Attachments: LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch Currently there is source code in lucene/tools/src (e.g. Forbidden APIs checker ant task). It would be convenient if you could download this thing in your ant build from ivy (especially if maybe it included our definitions .txt files as resources). In general checking for locale/charset violations in this way is a pretty general useful thing for a server-side app. Can we either release lucene-tools.jar as an artifact, or maybe alternatively move this somewhere else as a standalone project and suck it in ourselves? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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: Wild card support when stemmers are added
Thanks Jack. I will look at the option of implementing work around. --Saida Reddy. -- View this message in context: http://lucene.472066.n3.nabble.com/Wild-card-support-when-stemmers-are-added-tp4038402p4038511.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4570) Release ForbiddenAPI checker on Google Code
[ https://issues.apache.org/jira/browse/LUCENE-4570?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4570: -- Component/s: general/build Release ForbiddenAPI checker on Google Code --- Key: LUCENE-4570 URL: https://issues.apache.org/jira/browse/LUCENE-4570 Project: Lucene - Core Issue Type: New Feature Components: general/build Reporter: Robert Muir Assignee: Uwe Schindler Fix For: 4.2, 5.0 Attachments: LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch, LUCENE-4570.patch Currently there is source code in lucene/tools/src (e.g. Forbidden APIs checker ant task). It would be convenient if you could download this thing in your ant build from ivy (especially if maybe it included our definitions .txt files as resources). In general checking for locale/charset violations in this way is a pretty general useful thing for a server-side app. Can we either release lucene-tools.jar as an artifact, or maybe alternatively move this somewhere else as a standalone project and suck it in ourselves? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4753) Make forbidden API checks per-module
Uwe Schindler created LUCENE-4753:
-
Summary: Make forbidden API checks per-module
Key: LUCENE-4753
URL: https://issues.apache.org/jira/browse/LUCENE-4753
Project: Lucene - Core
Issue Type: Bug
Components: general/build
Reporter: Uwe Schindler
Assignee: Uwe Schindler
After the forbidden API checker was released separately from Lucene as a Google
Code project (forked and improved), including Maven support, the checks on
Lucene should be changed to work per-module.
The reason for this is: The improved checker is more picky about e.g. extending
classes that are forbidden or overriding methods and calling super.method() if
they are on the forbidden signatures list. For these checks, it is not enough
to have the class files and the rt.jar, you need the whole classpath. The
forbidden APIs 1.0 now by default complains if classes are missing from the
classpath.
It is very hard with the module architecture of Lucene/Solr, to make a
uber-classpath, instead the checks should be done per module, so the default
compile/test classpath of the module can be used and no crazy path statements
with **/*.jar are needed. This needs some refactoring in the exclusion lists,
but the Lucene checks could be done by a macro in common-build, that allows
custom exclusion lists for specific modules.
Currently, the strict checking is disabled for Solr, so the checker only
complains about missing classes but does not fail the build:
{noformat}
-check-forbidden-java-apis:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.6
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.6
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.1
[forbidden-apis] Reading API signatures: C:\Users\Uwe
Schindler\Projects\lucene\trunk-lusolr3\lucene\tools\forbiddenApis\executors.txt
[forbidden-apis] Reading API signatures: C:\Users\Uwe
Schindler\Projects\lucene\trunk-lusolr3\lucene\tools\forbiddenApis\servlet-api.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning for API signatures and dependencies...
[forbidden-apis] WARNING: The referenced class
'org.apache.lucene.analysis.uima.ae.AEProviderFactory' cannot be loaded. Please
fix the classpath!
[forbidden-apis] WARNING: The referenced class
'org.apache.lucene.analysis.uima.ae.AEProviderFactory' cannot be loaded. Please
fix the classpath!
[forbidden-apis] WARNING: The referenced class
'org.apache.lucene.analysis.uima.ae.AEProvider' cannot be loaded. Please fix
the classpath!
[forbidden-apis] WARNING: The referenced class
'org.apache.lucene.collation.ICUCollationKeyAnalyzer' cannot be loaded. Please
fix the classpath!
[forbidden-apis] Scanned 2177 (and 1222 related) class file(s) for forbidden
API invocations (in 1.80s), 0 error(s).
{noformat}
I added almost all missing jars, but those do not seem to be in the solr part
of the source tree (i think they are only copied when building artifacts). With
making the whole thing per module, we can use the default classpath of the
module which makes it much easier.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4753) Make forbidden API checks per-module
[
https://issues.apache.org/jira/browse/LUCENE-4753?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Uwe Schindler updated LUCENE-4753:
--
Issue Type: Improvement (was: Bug)
Make forbidden API checks per-module
Key: LUCENE-4753
URL: https://issues.apache.org/jira/browse/LUCENE-4753
Project: Lucene - Core
Issue Type: Improvement
Components: general/build
Reporter: Uwe Schindler
Assignee: Uwe Schindler
After the forbidden API checker was released separately from Lucene as a
Google Code project (forked and improved), including Maven support, the
checks on Lucene should be changed to work per-module.
The reason for this is: The improved checker is more picky about e.g.
extending classes that are forbidden or overriding methods and calling
super.method() if they are on the forbidden signatures list. For these
checks, it is not enough to have the class files and the rt.jar, you need the
whole classpath. The forbidden APIs 1.0 now by default complains if classes
are missing from the classpath.
It is very hard with the module architecture of Lucene/Solr, to make a
uber-classpath, instead the checks should be done per module, so the default
compile/test classpath of the module can be used and no crazy path statements
with **/*.jar are needed. This needs some refactoring in the exclusion lists,
but the Lucene checks could be done by a macro in common-build, that allows
custom exclusion lists for specific modules.
Currently, the strict checking is disabled for Solr, so the checker only
complains about missing classes but does not fail the build:
{noformat}
-check-forbidden-java-apis:
[forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.6
[forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.6
[forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.1
[forbidden-apis] Reading API signatures: C:\Users\Uwe
Schindler\Projects\lucene\trunk-lusolr3\lucene\tools\forbiddenApis\executors.txt
[forbidden-apis] Reading API signatures: C:\Users\Uwe
Schindler\Projects\lucene\trunk-lusolr3\lucene\tools\forbiddenApis\servlet-api.txt
[forbidden-apis] Loading classes to check...
[forbidden-apis] Scanning for API signatures and dependencies...
[forbidden-apis] WARNING: The referenced class
'org.apache.lucene.analysis.uima.ae.AEProviderFactory' cannot be loaded.
Please fix the classpath!
[forbidden-apis] WARNING: The referenced class
'org.apache.lucene.analysis.uima.ae.AEProviderFactory' cannot be loaded.
Please fix the classpath!
[forbidden-apis] WARNING: The referenced class
'org.apache.lucene.analysis.uima.ae.AEProvider' cannot be loaded. Please fix
the classpath!
[forbidden-apis] WARNING: The referenced class
'org.apache.lucene.collation.ICUCollationKeyAnalyzer' cannot be loaded.
Please fix the classpath!
[forbidden-apis] Scanned 2177 (and 1222 related) class file(s) for forbidden
API invocations (in 1.80s), 0 error(s).
{noformat}
I added almost all missing jars, but those do not seem to be in the solr part
of the source tree (i think they are only copied when building artifacts).
With making the whole thing per module, we can use the default classpath of
the module which makes it much easier.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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: Wild card support when stemmers are added
Guys, I'm a little bit out of context, but aren't you talking about http://searchhub.org/2011/11/29/whats-with-lowercasing-wildcard-multiterm-queries-in-solr/? On Tue, Feb 5, 2013 at 1:40 PM, msreddy.hi msreddy...@gmail.com wrote: Thanks Jack. I will look at the option of implementing work around. --Saida Reddy. -- View this message in context: http://lucene.472066.n3.nabble.com/Wild-card-support-when-stemmers-are-added-tp4038402p4038511.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Sincerely yours Mikhail Khludnev Principal Engineer, Grid Dynamics http://www.griddynamics.com mkhlud...@griddynamics.com
[jira] [Created] (LUCENE-4754) IndexWriter can't handle old lucene inex format when opened with create mode
i30817 created LUCENE-4754: -- Summary: IndexWriter can't handle old lucene inex format when opened with create mode Key: LUCENE-4754 URL: https://issues.apache.org/jira/browse/LUCENE-4754 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.1 Reporter: i30817 Priority: Minor IndexWriter indexWriter = new IndexWriter(cacheDir, new IndexWriterConfig(Version.LUCENE_41, englishAnalyzer). setOpenMode(IndexWriterConfig.OpenMode.CREATE)); Fails with CorruptedIndex subclass, IndexTooOldException (or something like that), even though the config would just replace the files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.6.0) - Build # 173 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/173/ Java: 64bit/jdk1.6.0 -XX:+UseSerialGC All tests passed Build Log: [...truncated 24724 lines...] BUILD FAILED /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/build.xml:60: The following error occurred while executing this line: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build.xml:536: The following error occurred while executing this line: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/common-build.xml:1993: java.net.UnknownHostException: issues.apache.org at java.net.PlainSocketImpl.connect(PlainSocketImpl.java:195) at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:432) at java.net.Socket.connect(Socket.java:529) at com.sun.net.ssl.internal.ssl.SSLSocketImpl.connect(SSLSocketImpl.java:570) at com.sun.net.ssl.internal.ssl.BaseSSLSocketImpl.connect(BaseSSLSocketImpl.java:141) at sun.net.NetworkClient.doConnect(NetworkClient.java:163) at sun.net.www.http.HttpClient.openServer(HttpClient.java:388) at sun.net.www.http.HttpClient.openServer(HttpClient.java:523) at sun.net.www.protocol.https.HttpsClient.init(HttpsClient.java:272) at sun.net.www.protocol.https.HttpsClient.New(HttpsClient.java:329) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.getNewHttpClient(AbstractDelegateHttpsURLConnection.java:172) at sun.net.www.protocol.http.HttpURLConnection.plainConnect(HttpURLConnection.java:911) at sun.net.www.protocol.https.AbstractDelegateHttpsURLConnection.connect(AbstractDelegateHttpsURLConnection.java:158) at sun.net.www.protocol.https.HttpsURLConnectionImpl.connect(HttpsURLConnectionImpl.java:133) at org.apache.tools.ant.taskdefs.Get$GetThread.openConnection(Get.java:660) at org.apache.tools.ant.taskdefs.Get$GetThread.get(Get.java:579) at org.apache.tools.ant.taskdefs.Get$GetThread.run(Get.java:569) Total time: 76 minutes 29 seconds Build step 'Invoke Ant' marked build as failure Archiving artifacts Recording test results Description set: Java: 64bit/jdk1.6.0 -XX:+UseSerialGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-4752) Sort documents when writing or merging segments
[ https://issues.apache.org/jira/browse/LUCENE-4752?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand reassigned LUCENE-4752: Assignee: Adrien Grand Sort documents when writing or merging segments --- Key: LUCENE-4752 URL: https://issues.apache.org/jira/browse/LUCENE-4752 Project: Lucene - Core Issue Type: New Feature Components: core/index Reporter: David Smiley Assignee: Adrien Grand It would be awesome if Lucene could write the documents out in a segment based on a configurable order. This of course applies to merging segments to. The benefit is increased locality on disk of documents that are likely to be accessed together. This often applies to documents near each other in time, but also spatially. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4751) IndexReader close throwing NullPointerException
[ https://issues.apache.org/jira/browse/LUCENE-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571242#comment-13571242 ] Michael McCandless commented on LUCENE-4751: You can try enabling compound file and/or decreasing your mergeFactor to reduce the open file count, or increase the limit set by your OS/shell. Are you using IndexReader.setNorm? IndexReader close throwing NullPointerException --- Key: LUCENE-4751 URL: https://issues.apache.org/jira/browse/LUCENE-4751 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 2.9.2 Environment: RedHat Reporter: Anusha Rao Hi, Has anyone seen the NullPointerException as shown below before? We have used Lucene to build a public site search functionality. All the IndexReader objects in there are closed appropriately except one that throws the following error and results in (too many files open) exception. This brings the entire site down. The lucene version we are using is lucene-core-2.9.2.jar Any idea what could cause this exception? java.lang.NullPointerException at org.apache.lucene.index.SegmentReader$Norm.decRef(SegmentReader.java:393) at org.apache.lucene.index.SegmentReader.doClose(SegmentReader.java:868) at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:170) at org.apache.lucene.index.DirectoryReader.doClose(DirectoryReader.java:803) at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:170) at org.apache.lucene.index.IndexReader.close(IndexReader.java:1302) at search.Searcher.search(Searcher.java:387) // the close in this class does not execute -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-1093) A RequestHandler to run multiple queries in a batch
[
https://issues.apache.org/jira/browse/SOLR-1093?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571244#comment-13571244
]
J Mohamed Zahoor commented on SOLR-1093:
Integration with solrj will be a nice addition
A RequestHandler to run multiple queries in a batch
---
Key: SOLR-1093
URL: https://issues.apache.org/jira/browse/SOLR-1093
Project: Solr
Issue Type: New Feature
Components: search
Reporter: Noble Paul
Assignee: Simon Willnauer
Attachments: SOLR-1093.patch
It is a common requirement that a single page requires to fire multiple
queries .In cases where these queries are independent of each other. If there
is a handler which can take in multiple queries , run them in paralll and
send the response as one big chunk it would be useful
Let us say the handler is MultiRequestHandler
{code}
requestHandler name=/multi class=solr.MultiRequestHandler/
{code}
h2.Query Syntax
The request must specify the no:of queries as count=n
Each request parameter must be prefixed with a number which denotes the query
index.optionally ,it may can also specify the handler name.
example
{code}
/multi?count=21.handler=/select1.q=a:b2.handler=/select2.q=a:c
{code}
default handler can be '/select' so the equivalent can be
{code}
/multi?count=21.q=a:b2.q=a:c
{code}
h2.The response
The response will be a ListNamedList where each NamedList will be a
response to a query.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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
LBHttpSolrServer not recommended for updates out-of-date prohibition?
http://wiki.apache.org/solr/LBHttpSolrServer Has prohibitions against using for updates. I'm assuming that this is for non-cloud mode, right? 'Cause I looked at CloudSolrServer and it uses LBHttpSolrServer, so I was a bit uncertain. I'm guessing a case of a little knowledge being dangerous. Should I update the Wiki for LBHttpSolrServer? I'm thinking something along the lines of pointing out that the _reason_ LBHttpSolrServer is a Bad Thing for Updates when NOT in SolrCloud is that updates would then go to non-master nodes, but that doesn't apply in SolrCloud. That said, one should use CloudSolrServer rather than LBHttpSolrServer directly. Erick
[jira] [Resolved] (LUCENE-4754) IndexWriter can't handle old lucene inex format when opened with create mode
[ https://issues.apache.org/jira/browse/LUCENE-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved LUCENE-4754. Resolution: Not A Problem Please raise this kind of issue on the user's list before creating a JIRA. I believe that this is correct behavior. But you haven't provided enough detail to say one way or another. IndexWriter can't handle old lucene inex format when opened with create mode Key: LUCENE-4754 URL: https://issues.apache.org/jira/browse/LUCENE-4754 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.1 Reporter: i30817 Priority: Minor IndexWriter indexWriter = new IndexWriter(cacheDir, new IndexWriterConfig(Version.LUCENE_41, englishAnalyzer). setOpenMode(IndexWriterConfig.OpenMode.CREATE)); Fails with CorruptedIndex subclass, IndexTooOldException (or something like that), even though the config would just replace the files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4755) Unmap MMapIndexInput's in a delayed way, and avoid WeakReference usage.
Kristofer Karlsson created LUCENE-4755:
--
Summary: Unmap MMapIndexInput's in a delayed way, and avoid
WeakReference usage.
Key: LUCENE-4755
URL: https://issues.apache.org/jira/browse/LUCENE-4755
Project: Lucene - Core
Issue Type: Improvement
Components: core/store
Reporter: Kristofer Karlsson
(Most of this is shamelessly borrowed from Uwe Schindler)
It would be nice to move away from using WeakReference to clean up clones.
Instead, the clones could depend on the master by using a shared boolean
closed-flag.
In order to ensure visibility of this value, or at least make it less likely to
crash, we could delay the unmapping operation.
Rough suggestion of changes:
code
public class ByteBufferUnmapper {
/**
* codetrue/code, if this platform supports unmapping mmapped files.
*/
public static final boolean UNMAP_SUPPORTED;
private static final ScheduledExecutorService SCHEDULED_EXECUTOR_SERVICE =
Executors.newSingleThreadScheduledExecutor(new NamedThreadFactory(unmapper-));
static {
boolean v = false;
try {
Class.forName(sun.misc.Cleaner);
Class.forName(java.nio.DirectByteBuffer)
.getMethod(cleaner);
v = true;
} catch (Exception e) {
// Do nothing
} finally {
UNMAP_SUPPORTED = v;
}
}
public static void unmap(final ByteBuffer buffer) throws IOException {
try {
AccessController.doPrivileged(new PrivilegedExceptionActionObject() {
public Object run() throws Exception {
Method getCleanerMethod = buffer.getClass().getMethod(cleaner);
getCleanerMethod.setAccessible(true);
final Object cleaner = getCleanerMethod.invoke(buffer);
if (cleaner != null) {
cleaner.getClass().getMethod(clean).invoke(cleaner);
}
return null;
}
});
} catch (PrivilegedActionException e) {
final IOException ioe = new IOException(unable to unmap the mapped
buffer);
ioe.initCause(e.getCause());
throw ioe;
}
}
public static void unmapLater(final ByteBuffer buffer, long delay, TimeUnit
unit) {
SCHEDULED_EXECUTOR_SERVICE.schedule(new Runnable() {
public void run() {
try {
unmap(buffer);
} catch (IOException e) {
e.printStackTrace();
}
}
}, delay, unit);
}
}
/code
code
// MMapDirectory
final void cleanMapping(final ByteBuffer buffer) throws IOException {
if (useUnmapHack) {
ByteBufferUnmapper.unmapLater(buffer, 10, TimeUnit.SECONDS);
}
}
/code
code
// MMapIndexInput
@Override
public short readShort() throws IOException {
if (closed[0]) {
throw new AlreadyClosedException(MMapIndexInput already closed: +
this);
}
/code
code
@Override
public void close() throws IOException {
try {
if (isClone || buffers == null) return;
closed[0] = true;
// make local copy, then un-set early
final ByteBuffer[] bufs = buffers;
for (final ByteBuffer b : bufs) {
cleanMapping(b);
}
} finally {
unsetBuffers();
}
}
/code
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4755) Unmap MMapIndexInput's in a delayed way, and avoid WeakReference usage.
[
https://issues.apache.org/jira/browse/LUCENE-4755?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Kristofer Karlsson updated LUCENE-4755:
---
Description:
(Most of this is shamelessly borrowed from Uwe Schindler)
It would be nice to move away from using WeakReference to clean up clones.
Instead, the clones could depend on the master by using a shared boolean
closed-flag.
In order to ensure visibility of this value, or at least make it less likely to
crash, we could delay the unmapping operation.
Rough suggestion of changes:
{code:java}
public class ByteBufferUnmapper {
/**
* codetrue/code, if this platform supports unmapping mmapped files.
*/
public static final boolean UNMAP_SUPPORTED;
private static final ScheduledExecutorService SCHEDULED_EXECUTOR_SERVICE =
Executors.newSingleThreadScheduledExecutor(new NamedThreadFactory(unmapper-));
static {
boolean v = false;
try {
Class.forName(sun.misc.Cleaner);
Class.forName(java.nio.DirectByteBuffer)
.getMethod(cleaner);
v = true;
} catch (Exception e) {
// Do nothing
} finally {
UNMAP_SUPPORTED = v;
}
}
public static void unmap(final ByteBuffer buffer) throws IOException {
try {
AccessController.doPrivileged(new PrivilegedExceptionActionObject() {
public Object run() throws Exception {
Method getCleanerMethod = buffer.getClass().getMethod(cleaner);
getCleanerMethod.setAccessible(true);
final Object cleaner = getCleanerMethod.invoke(buffer);
if (cleaner != null) {
cleaner.getClass().getMethod(clean).invoke(cleaner);
}
return null;
}
});
} catch (PrivilegedActionException e) {
final IOException ioe = new IOException(unable to unmap the mapped
buffer);
ioe.initCause(e.getCause());
throw ioe;
}
}
public static void unmapLater(final ByteBuffer buffer, long delay, TimeUnit
unit) {
SCHEDULED_EXECUTOR_SERVICE.schedule(new Runnable() {
public void run() {
try {
unmap(buffer);
} catch (IOException e) {
e.printStackTrace();
}
}
}, delay, unit);
}
}
{code}
{code:java}
// MMapDirectory
final void cleanMapping(final ByteBuffer buffer) throws IOException {
if (useUnmapHack) {
ByteBufferUnmapper.unmapLater(buffer, 10, TimeUnit.SECONDS);
}
}
{code}
{code:java}
// MMapIndexInput
@Override
public short readShort() throws IOException {
if (closed[0]) {
throw new AlreadyClosedException(MMapIndexInput already closed: +
this);
}
{code}
{code:java}
@Override
public void close() throws IOException {
try {
if (isClone || buffers == null) return;
closed[0] = true;
// make local copy, then un-set early
final ByteBuffer[] bufs = buffers;
for (final ByteBuffer b : bufs) {
cleanMapping(b);
}
} finally {
unsetBuffers();
}
}
{code}
was:
(Most of this is shamelessly borrowed from Uwe Schindler)
It would be nice to move away from using WeakReference to clean up clones.
Instead, the clones could depend on the master by using a shared boolean
closed-flag.
In order to ensure visibility of this value, or at least make it less likely to
crash, we could delay the unmapping operation.
Rough suggestion of changes:
code
public class ByteBufferUnmapper {
/**
* codetrue/code, if this platform supports unmapping mmapped files.
*/
public static final boolean UNMAP_SUPPORTED;
private static final ScheduledExecutorService SCHEDULED_EXECUTOR_SERVICE =
Executors.newSingleThreadScheduledExecutor(new NamedThreadFactory(unmapper-));
static {
boolean v = false;
try {
Class.forName(sun.misc.Cleaner);
Class.forName(java.nio.DirectByteBuffer)
.getMethod(cleaner);
v = true;
} catch (Exception e) {
// Do nothing
} finally {
UNMAP_SUPPORTED = v;
}
}
public static void unmap(final ByteBuffer buffer) throws IOException {
try {
AccessController.doPrivileged(new PrivilegedExceptionActionObject() {
public Object run() throws Exception {
Method getCleanerMethod = buffer.getClass().getMethod(cleaner);
getCleanerMethod.setAccessible(true);
final Object cleaner = getCleanerMethod.invoke(buffer);
if (cleaner != null) {
cleaner.getClass().getMethod(clean).invoke(cleaner);
}
return null;
}
});
} catch (PrivilegedActionException e) {
final IOException ioe = new IOException(unable to unmap the mapped
buffer);
ioe.initCause(e.getCause());
throw ioe;
}
}
public static void unmapLater(final ByteBuffer buffer, long delay, TimeUnit
unit) {
SCHEDULED_EXECUTOR_SERVICE.schedule(new Runnable() {
[jira] [Created] (SOLR-4404) Update LBHttpSolrServer docs to un-confuse the use in updates.
Erick Erickson created SOLR-4404: Summary: Update LBHttpSolrServer docs to un-confuse the use in updates. Key: SOLR-4404 URL: https://issues.apache.org/jira/browse/SOLR-4404 Project: Solr Issue Type: Improvement Affects Versions: 4.1, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Trivial Fix For: 4.2, 5.0 It's a bit confusing. We link from CloudSolrServer to LBHttpSolrServer, where it says do NOT use this for updates. Update LBHttpSolrServer to draw the distinction between cloud and non-cloud updates. I'll do this this weekend, just don't want to lose track. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4728) Allow CommonTermsQuery to be highlighted
[ https://issues.apache.org/jira/browse/LUCENE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-4728: Attachment: LUCENE-4728.patch next iter, updated changes entry and cleaned up WeigthedSpanTermExtractor a bit. I will commit this in a bit. Allow CommonTermsQuery to be highlighted Key: LUCENE-4728 URL: https://issues.apache.org/jira/browse/LUCENE-4728 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Affects Versions: 4.1 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.2, 5.0 Attachments: LUCENE-4728.patch, LUCENE-4728.patch, LUCENE-4728.patch, LUCENE-4728.patch Add support for CommonTermsQuery to all highlighter impls. This might add a dependency (query-jar) to the highlighter so we might think about adding it to core? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4728) Allow CommonTermsQuery to be highlighted
[ https://issues.apache.org/jira/browse/LUCENE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571310#comment-13571310 ] Commit Tag Bot commented on LUCENE-4728: [trunk commit] Simon Willnauer http://svn.apache.org/viewvc?view=revisionrevision=1442590 LUCENE-4728: Unknown and not explicitly mapped queries are now rewritten against the highlighting IndexReader to obtain primitive queries before discarding the query entirely. Allow CommonTermsQuery to be highlighted Key: LUCENE-4728 URL: https://issues.apache.org/jira/browse/LUCENE-4728 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Affects Versions: 4.1 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.2, 5.0 Attachments: LUCENE-4728.patch, LUCENE-4728.patch, LUCENE-4728.patch, LUCENE-4728.patch Add support for CommonTermsQuery to all highlighter impls. This might add a dependency (query-jar) to the highlighter so we might think about adding it to core? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4745) Allow FuzzySlop customization in classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-4745: Priority: Minor (was: Major) Allow FuzzySlop customization in classic QueryParser Key: LUCENE-4745 URL: https://issues.apache.org/jira/browse/LUCENE-4745 Project: Lucene - Core Issue Type: Improvement Components: modules/queryparser Affects Versions: 4.1 Reporter: Florian Schilling Assignee: Simon Willnauer Priority: Minor Fix For: 4.2, 5.0 Attachments: LUCENE-4745-full.patch, LUCENE-4745-full.patch, LUCENE-4745-raw.patch, LUCENE-4745-raw.patch It turns out searching arbitrary fields with define FUZZY_SLOP values could be problematic on some types of values. For example a FUZZY_SLOP on dates is ambiguous and needs a definition of a unit like months, days, minutes, etc. An extension on the query grammar that allows some arbitrary text behind the values in combination with a possibility to override the method parsing those values could solve these kinds of problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4745) Allow FuzzySlop customization in classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571329#comment-13571329 ] Commit Tag Bot commented on LUCENE-4745: [trunk commit] Simon Willnauer http://svn.apache.org/viewvc?view=revisionrevision=1442596 LUCENE-4745: Allow FuzzySlop customization in classic QueryParser Allow FuzzySlop customization in classic QueryParser Key: LUCENE-4745 URL: https://issues.apache.org/jira/browse/LUCENE-4745 Project: Lucene - Core Issue Type: Improvement Components: modules/queryparser Affects Versions: 4.1 Reporter: Florian Schilling Assignee: Simon Willnauer Priority: Minor Fix For: 4.2, 5.0 Attachments: LUCENE-4745-full.patch, LUCENE-4745-full.patch, LUCENE-4745-raw.patch, LUCENE-4745-raw.patch It turns out searching arbitrary fields with define FUZZY_SLOP values could be problematic on some types of values. For example a FUZZY_SLOP on dates is ambiguous and needs a definition of a unit like months, days, minutes, etc. An extension on the query grammar that allows some arbitrary text behind the values in combination with a possibility to override the method parsing those values could solve these kinds of problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.6.0_38) - Build # 4163 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/4163/ Java: 32bit/jdk1.6.0_38 -client -XX:+UseParallelGC 2 tests failed. REGRESSION: org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testHighlightingTV Error Message: org/apache/lucene/queries/CommonTermsQuery Stack Trace: java.lang.NoClassDefFoundError: org/apache/lucene/queries/CommonTermsQuery at __randomizedtesting.SeedInfo.seed([459AF679CD1959C0:25B8D00F5206B159]:0) at org.apache.lucene.search.highlight.WeightedSpanTermExtractor.extract(WeightedSpanTermExtractor.java:147) at org.apache.lucene.search.highlight.WeightedSpanTermExtractor.getWeightedSpanTerms(WeightedSpanTermExtractor.java:457) at org.apache.lucene.search.highlight.QueryScorer.initExtractor(QueryScorer.java:217) at org.apache.lucene.search.highlight.QueryScorer.init(QueryScorer.java:186) at org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:199) at org.apache.lucene.benchmark.byTask.tasks.CountingHighlighterTestTask$1.doHighlight(CountingHighlighterTestTask.java:63) at org.apache.lucene.benchmark.byTask.tasks.ReadTask.doLogic(ReadTask.java:174) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:146) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doSerialTasks(TaskSequence.java:197) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doLogic(TaskSequence.java:138) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:146) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doSerialTasks(TaskSequence.java:197) at org.apache.lucene.benchmark.byTask.tasks.TaskSequence.doLogic(TaskSequence.java:138) at org.apache.lucene.benchmark.byTask.tasks.PerfTask.runAndMaybeStats(PerfTask.java:146) at org.apache.lucene.benchmark.byTask.utils.Algorithm.execute(Algorithm.java:331) at org.apache.lucene.benchmark.byTask.Benchmark.execute(Benchmark.java:77) at org.apache.lucene.benchmark.BenchmarkTestCase.execBenchmark(BenchmarkTestCase.java:83) at org.apache.lucene.benchmark.byTask.TestPerfTasksLogic.testHighlightingTV(TestPerfTasksLogic.java:228) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at
[jira] [Commented] (LUCENE-4728) Allow CommonTermsQuery to be highlighted
[ https://issues.apache.org/jira/browse/LUCENE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571334#comment-13571334 ] Commit Tag Bot commented on LUCENE-4728: [branch_4x commit] Simon Willnauer http://svn.apache.org/viewvc?view=revisionrevision=1442599 LUCENE-4728: Unknown and not explicitly mapped queries are now rewritten against the highlighting IndexReader to obtain primitive queries before discarding the query entirely. Allow CommonTermsQuery to be highlighted Key: LUCENE-4728 URL: https://issues.apache.org/jira/browse/LUCENE-4728 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Affects Versions: 4.1 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.2, 5.0 Attachments: LUCENE-4728.patch, LUCENE-4728.patch, LUCENE-4728.patch, LUCENE-4728.patch Add support for CommonTermsQuery to all highlighter impls. This might add a dependency (query-jar) to the highlighter so we might think about adding it to core? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4728) Allow CommonTermsQuery to be highlighted
[ https://issues.apache.org/jira/browse/LUCENE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer resolved LUCENE-4728. - Resolution: Fixed Allow CommonTermsQuery to be highlighted Key: LUCENE-4728 URL: https://issues.apache.org/jira/browse/LUCENE-4728 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Affects Versions: 4.1 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.2, 5.0 Attachments: LUCENE-4728.patch, LUCENE-4728.patch, LUCENE-4728.patch, LUCENE-4728.patch Add support for CommonTermsQuery to all highlighter impls. This might add a dependency (query-jar) to the highlighter so we might think about adding it to core? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4745) Allow FuzzySlop customization in classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer resolved LUCENE-4745. - Resolution: Fixed thanks florian Allow FuzzySlop customization in classic QueryParser Key: LUCENE-4745 URL: https://issues.apache.org/jira/browse/LUCENE-4745 Project: Lucene - Core Issue Type: Improvement Components: modules/queryparser Affects Versions: 4.1 Reporter: Florian Schilling Assignee: Simon Willnauer Priority: Minor Fix For: 4.2, 5.0 Attachments: LUCENE-4745-full.patch, LUCENE-4745-full.patch, LUCENE-4745-raw.patch, LUCENE-4745-raw.patch It turns out searching arbitrary fields with define FUZZY_SLOP values could be problematic on some types of values. For example a FUZZY_SLOP on dates is ambiguous and needs a definition of a unit like months, days, minutes, etc. An extension on the query grammar that allows some arbitrary text behind the values in combination with a possibility to override the method parsing those values could solve these kinds of problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4745) Allow FuzzySlop customization in classic QueryParser
[ https://issues.apache.org/jira/browse/LUCENE-4745?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571340#comment-13571340 ] Commit Tag Bot commented on LUCENE-4745: [branch_4x commit] Simon Willnauer http://svn.apache.org/viewvc?view=revisionrevision=1442604 LUCENE-4745: Allow FuzzySlop customization in classic QueryParser Allow FuzzySlop customization in classic QueryParser Key: LUCENE-4745 URL: https://issues.apache.org/jira/browse/LUCENE-4745 Project: Lucene - Core Issue Type: Improvement Components: modules/queryparser Affects Versions: 4.1 Reporter: Florian Schilling Assignee: Simon Willnauer Priority: Minor Fix For: 4.2, 5.0 Attachments: LUCENE-4745-full.patch, LUCENE-4745-full.patch, LUCENE-4745-raw.patch, LUCENE-4745-raw.patch It turns out searching arbitrary fields with define FUZZY_SLOP values could be problematic on some types of values. For example a FUZZY_SLOP on dates is ambiguous and needs a definition of a unit like months, days, minutes, etc. An extension on the query grammar that allows some arbitrary text behind the values in combination with a possibility to override the method parsing those values could solve these kinds of problems. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4751) IndexReader close throwing NullPointerException
[ https://issues.apache.org/jira/browse/LUCENE-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571344#comment-13571344 ] Anusha Rao commented on LUCENE-4751: No we are notusing IndexReader.setNorm. Just opening the reader. Reading indexes and closing it. the limit of the OS is set to large number already about 8 or so On Tue, Feb 5, 2013 at 6:39 AM, Michael McCandless (JIRA) IndexReader close throwing NullPointerException --- Key: LUCENE-4751 URL: https://issues.apache.org/jira/browse/LUCENE-4751 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 2.9.2 Environment: RedHat Reporter: Anusha Rao Hi, Has anyone seen the NullPointerException as shown below before? We have used Lucene to build a public site search functionality. All the IndexReader objects in there are closed appropriately except one that throws the following error and results in (too many files open) exception. This brings the entire site down. The lucene version we are using is lucene-core-2.9.2.jar Any idea what could cause this exception? java.lang.NullPointerException at org.apache.lucene.index.SegmentReader$Norm.decRef(SegmentReader.java:393) at org.apache.lucene.index.SegmentReader.doClose(SegmentReader.java:868) at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:170) at org.apache.lucene.index.DirectoryReader.doClose(DirectoryReader.java:803) at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:170) at org.apache.lucene.index.IndexReader.close(IndexReader.java:1302) at search.Searcher.search(Searcher.java:387) // the close in this class does not execute -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4751) IndexReader close throwing NullPointerException
[ https://issues.apache.org/jira/browse/LUCENE-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571346#comment-13571346 ] Anusha Rao commented on LUCENE-4751: Simon, Thanks for your reply. The limit of the open files is already set to a big number about 8 or so. Do you think there was an issue with the older lucene core jar with this respect? IndexReader close throwing NullPointerException --- Key: LUCENE-4751 URL: https://issues.apache.org/jira/browse/LUCENE-4751 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 2.9.2 Environment: RedHat Reporter: Anusha Rao Hi, Has anyone seen the NullPointerException as shown below before? We have used Lucene to build a public site search functionality. All the IndexReader objects in there are closed appropriately except one that throws the following error and results in (too many files open) exception. This brings the entire site down. The lucene version we are using is lucene-core-2.9.2.jar Any idea what could cause this exception? java.lang.NullPointerException at org.apache.lucene.index.SegmentReader$Norm.decRef(SegmentReader.java:393) at org.apache.lucene.index.SegmentReader.doClose(SegmentReader.java:868) at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:170) at org.apache.lucene.index.DirectoryReader.doClose(DirectoryReader.java:803) at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:170) at org.apache.lucene.index.IndexReader.close(IndexReader.java:1302) at search.Searcher.search(Searcher.java:387) // the close in this class does not execute -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4754) IndexWriter can't handle old lucene inex format when opened with create mode
[ https://issues.apache.org/jira/browse/LUCENE-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571350#comment-13571350 ] Michael McCandless commented on LUCENE-4754: Actually this is sort of odd: since IW was asked to CREATE ... it should not have been reading anything from the index that would lead to IndexFormatTooOldException. Do you have the full exception? Did you hit the exception on opening IndexWriter, or later (during indexing/committing or something). IndexWriter can't handle old lucene inex format when opened with create mode Key: LUCENE-4754 URL: https://issues.apache.org/jira/browse/LUCENE-4754 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.1 Reporter: i30817 Priority: Minor IndexWriter indexWriter = new IndexWriter(cacheDir, new IndexWriterConfig(Version.LUCENE_41, englishAnalyzer). setOpenMode(IndexWriterConfig.OpenMode.CREATE)); Fails with CorruptedIndex subclass, IndexTooOldException (or something like that), even though the config would just replace the files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4751) IndexReader close throwing NullPointerException
[ https://issues.apache.org/jira/browse/LUCENE-4751?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571357#comment-13571357 ] Michael McCandless commented on LUCENE-4751: 8 is plenty. But are you certain that's the actual limit? The shell also has its own limits ... eg try running ulimit -n Can you make a separate test case showing that NPE in IR.close? Also, try turning on assertions ... it may catch something sooner. IndexReader close throwing NullPointerException --- Key: LUCENE-4751 URL: https://issues.apache.org/jira/browse/LUCENE-4751 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 2.9.2 Environment: RedHat Reporter: Anusha Rao Hi, Has anyone seen the NullPointerException as shown below before? We have used Lucene to build a public site search functionality. All the IndexReader objects in there are closed appropriately except one that throws the following error and results in (too many files open) exception. This brings the entire site down. The lucene version we are using is lucene-core-2.9.2.jar Any idea what could cause this exception? java.lang.NullPointerException at org.apache.lucene.index.SegmentReader$Norm.decRef(SegmentReader.java:393) at org.apache.lucene.index.SegmentReader.doClose(SegmentReader.java:868) at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:170) at org.apache.lucene.index.DirectoryReader.doClose(DirectoryReader.java:803) at org.apache.lucene.index.IndexReader.decRef(IndexReader.java:170) at org.apache.lucene.index.IndexReader.close(IndexReader.java:1302) at search.Searcher.search(Searcher.java:387) // the close in this class does not execute -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4728) Allow CommonTermsQuery to be highlighted
[ https://issues.apache.org/jira/browse/LUCENE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571377#comment-13571377 ] Commit Tag Bot commented on LUCENE-4728: [trunk commit] Simon Willnauer http://svn.apache.org/viewvc?view=revisionrevision=1442605 LUCENE-4728: add queries to the classpath since highlighter specializes a query now Allow CommonTermsQuery to be highlighted Key: LUCENE-4728 URL: https://issues.apache.org/jira/browse/LUCENE-4728 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Affects Versions: 4.1 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.2, 5.0 Attachments: LUCENE-4728.patch, LUCENE-4728.patch, LUCENE-4728.patch, LUCENE-4728.patch Add support for CommonTermsQuery to all highlighter impls. This might add a dependency (query-jar) to the highlighter so we might think about adding it to core? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4728) Allow CommonTermsQuery to be highlighted
[ https://issues.apache.org/jira/browse/LUCENE-4728?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571376#comment-13571376 ] Commit Tag Bot commented on LUCENE-4728: [branch_4x commit] Simon Willnauer http://svn.apache.org/viewvc?view=revisionrevision=1442606 LUCENE-4728: add queries to the classpath since highlighter specializes a query now Allow CommonTermsQuery to be highlighted Key: LUCENE-4728 URL: https://issues.apache.org/jira/browse/LUCENE-4728 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Affects Versions: 4.1 Reporter: Simon Willnauer Assignee: Simon Willnauer Fix For: 4.2, 5.0 Attachments: LUCENE-4728.patch, LUCENE-4728.patch, LUCENE-4728.patch, LUCENE-4728.patch Add support for CommonTermsQuery to all highlighter impls. This might add a dependency (query-jar) to the highlighter so we might think about adding it to core? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-2850) Do not refine facets when minCount == 1
[ https://issues.apache.org/jira/browse/SOLR-2850?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand updated SOLR-2850: --- Attachment: SOLR-2850.patch Looks good. I've hit a similar issue with facet.sort=count so I updated your patch. Tests passed, I'll commit soon unless someone objects. Do not refine facets when minCount == 1 --- Key: SOLR-2850 URL: https://issues.apache.org/jira/browse/SOLR-2850 Project: Solr Issue Type: Improvement Components: SearchComponents - other Affects Versions: 3.4 Environment: Ubuntu, distributed Reporter: Matt Smith Attachments: SOLR-2850.patch, SOLR-2850.patch Currently there is a special case in the code to not refine facets if minCount==0. It seems this could be extended to minCount = 1 as there would be no need to take the extra step to refine facets if minCount is 1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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: LBHttpSolrServer not recommended for updates out-of-date prohibition?
On 2/5/2013 5:21 AM, Erick Erickson wrote: http://wiki.apache.org/solr/LBHttpSolrServer Has prohibitions against using for updates. I'm assuming that this is for non-cloud mode, right? 'Cause I looked at CloudSolrServer and it uses LBHttpSolrServer, so I was a bit uncertain. I'm guessing a case of a little knowledge being dangerous. Should I update the Wiki for LBHttpSolrServer? I'm thinking something along the lines of pointing out that the _reason_ LBHttpSolrServer is a Bad Thing for Updates when NOT in SolrCloud is that updates would then go to non-master nodes, but that doesn't apply in SolrCloud. That said, one should use CloudSolrServer rather than LBHttpSolrServer directly. I would think that CloudSolrServer would always be the recommendation when using SolrCloud. For some reason I thought that LBHttpSolrServer and CloudSolrServer had been added together, but apparently the LB object has been around since 1.4! My personal opinion (as a relative SolrCloud newbie) is that the warning about not using it for indexing should remain in place, with an addition that says something like If your servers are running SolrCloud, use CloudSolrServer. CloudSolrServer talks to zookeeper and is always aware of the cluster state. This would actually be a good addition to the javadoc for all SolrServer implementations. Is there a way to retroactively add this to the published 4.0 javadocs without a full 4.0.1 release? Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4405) Optional admin html inserts fail on Chrome and Safari (Mac): admin-extra.menu-top.html and admin-extra.menu-bottom.html
Alexandre Rafalovitch created SOLR-4405: --- Summary: Optional admin html inserts fail on Chrome and Safari (Mac): admin-extra.menu-top.html and admin-extra.menu-bottom.html Key: SOLR-4405 URL: https://issues.apache.org/jira/browse/SOLR-4405 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.1 Reporter: Alexandre Rafalovitch Priority: Minor Fix For: 4.2 Including admin-extra.html file in conf directory works - shows up on that core's admin page. Doing that for the other two files admin-extra.menu-top.html and admin-extra.menu-bottom.html fails: Uncaught Error: HIERARCHY_REQUEST_ERR: DOM Exception 3 require.js:8424 jQuery.extend.clean require.js:8424 jQuery.buildFragment require.js:8176 jQuery.fn.extend.domManip require.js:8003 jQuery.fn.extend.prepend require.js:7822 (anonymous function) dashboard.js:62 fire require.js:3099 self.fireWith require.js:3217 done require.js:9454 callback require.js:10235 I tried file content with li/li and with h1.../h1 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4754) IndexWriter can't handle old lucene inex format when opened with create mode
[ https://issues.apache.org/jira/browse/LUCENE-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571540#comment-13571540 ] i30817 commented on LUCENE-4754: From opening the indexwriter. I no longer have the log for the exception because i resolved it (by deletion of the index in certain situations) but i can probably recreate it. IndexWriter can't handle old lucene inex format when opened with create mode Key: LUCENE-4754 URL: https://issues.apache.org/jira/browse/LUCENE-4754 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.1 Reporter: i30817 Priority: Minor IndexWriter indexWriter = new IndexWriter(cacheDir, new IndexWriterConfig(Version.LUCENE_41, englishAnalyzer). setOpenMode(IndexWriterConfig.OpenMode.CREATE)); Fails with CorruptedIndex subclass, IndexTooOldException (or something like that), even though the config would just replace the files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4078) Allow custom naming of nodes so that a new host:port combination can take over for a previous shard.
[ https://issues.apache.org/jira/browse/SOLR-4078?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571543#comment-13571543 ] Michael Della Bitta commented on SOLR-4078: --- +1 definitely interested. Allow custom naming of nodes so that a new host:port combination can take over for a previous shard. Key: SOLR-4078 URL: https://issues.apache.org/jira/browse/SOLR-4078 Project: Solr Issue Type: New Feature Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 4.2, 5.0 Attachments: SOLR-4078.patch Currently we auto assign a unique node name based on the host address and core name - we should let the user optionally override this so that a new host address + core name combo can take over the duties of a previous registered node. Especially useful for ec2 if you are not using elastic ips. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3251) dynamically add field to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571548#comment-13571548
]
Steve Rowe commented on SOLR-3251:
--
I'm interested in working on this issue. I'm new to the ways of Solr dev,
though, so I'd appreciate assistance in getting things done right.
{quote}
Thinking a little further about this, building a new schema when it changes
(i.e. making schema effectively immutable), might be a good idea too.
For performance reasons, we'd want to share/reuse objects across the different
schema instances of course.
{quote}
The DOM for the previous schema could be kept around and compared to the DOM
for the new schema, and each object could keep a reference to the DOM node from
which it came. When corresponding DOM nodes compare as equal, then reloading
that object isn't necessary.
Keeping the DOM around would also allow for round-tripping comments and
whitespace, since those can be stored in the DOM. To make the new schema's DOM
on the node handling the add field request, copy the old DOM, then insert a
node for the new field. On second thought, I think it makes sense for the DOM
to be mutable, and not require a full copy on minting a new schema, since
otherwise unchanged objects would need to be modified to point to their new DOM
node, and objects in the old schema will no longer refer to the old DOM.
dynamically add field to schema
---
Key: SOLR-3251
URL: https://issues.apache.org/jira/browse/SOLR-3251
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Attachments: SOLR-3251.patch
One related piece of functionality needed for SOLR-3250 is the ability to
dynamically add a field to the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-4754) IndexWriter can't handle old lucene inex format when opened with create mode
[ https://issues.apache.org/jira/browse/LUCENE-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571558#comment-13571558 ] i30817 commented on LUCENE-4754: Here it is: Feb 05, 2013 6:33:11 PM i3.gutenberg.GutenbergSearch$1 run WARNING: Indexing interrupted org.apache.lucene.index.IndexFormatTooOldException: Format version is not supported (resource: MMapIndexInput(path=/home/paulo/.config/bookjar/gutenberg/_0.cfs) [slice=_0.fdx]): 1 (needs to be between 2 and 3). This version of Lucene only supports indexes created with release 3.0 and later. at org.apache.lucene.codecs.lucene3x.Lucene3xStoredFieldsReader.checkCodeVersion(Lucene3xStoredFieldsReader.java:119) at org.apache.lucene.codecs.lucene3x.Lucene3xSegmentInfoReader.readLegacyInfos(Lucene3xSegmentInfoReader.java:74) at org.apache.lucene.index.SegmentInfos.read(SegmentInfos.java:312) at org.apache.lucene.index.IndexFileDeleter.init(IndexFileDeleter.java:172) at org.apache.lucene.index.IndexWriter.init(IndexWriter.java:704) at i3.gutenberg.GutenbergSearch.prepare(GutenbergSearch.java:148) at i3.gutenberg.GutenbergSearch.access$000(GutenbergSearch.java:44) at i3.gutenberg.GutenbergSearch$1.run(GutenbergSearch.java:125) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) at java.lang.Thread.run(Thread.java:722) IndexWriter can't handle old lucene inex format when opened with create mode Key: LUCENE-4754 URL: https://issues.apache.org/jira/browse/LUCENE-4754 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.1 Reporter: i30817 Priority: Minor IndexWriter indexWriter = new IndexWriter(cacheDir, new IndexWriterConfig(Version.LUCENE_41, englishAnalyzer). setOpenMode(IndexWriterConfig.OpenMode.CREATE)); Fails with CorruptedIndex subclass, IndexTooOldException (or something like that), even though the config would just replace the files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 175 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/175/ Java: 64bit/jdk1.7.0 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 8938 lines...] [junit4:junit4] ERROR: JVM J0 ended with an exception, command line: /Library/Java/JavaVirtualMachines/jdk1.7.0_10.jdk/Contents/Home/jre/bin/java -XX:+UseConcMarkSweepGC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/heapdumps -Dtests.prefix=tests -Dtests.seed=8D95DDBB35888BA3 -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=4.2 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/testlogging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. -Djava.io.tmpdir=. -Djunit4.tempDir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/solr/build/solr-core/test/temp -Dclover.db.dir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/junit4/tests.policy -Dlucene.version=4.2-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -classpath
[jira] [Commented] (LUCENE-4754) IndexWriter can't handle old lucene inex format when opened with create mode
[ https://issues.apache.org/jira/browse/LUCENE-4754?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571596#comment-13571596 ] Michael McCandless commented on LUCENE-4754: Thanks i30817, I see what's happening: IndexWriter created a new (empty) SegmentInfos in memory, but it also goes and loads any prior commit points in the index and then gives IndexDeletionPolicy a chance (onInit) to delete them. The problem is, it cannot load those prior commit points since they are too old ... So realistically I don't think we can fix this, ie the app/user must fully delete the ancient index even with OpenNode.CREATE. But thanks for raising this! IndexWriter can't handle old lucene inex format when opened with create mode Key: LUCENE-4754 URL: https://issues.apache.org/jira/browse/LUCENE-4754 Project: Lucene - Core Issue Type: Bug Affects Versions: 4.1 Reporter: i30817 Priority: Minor IndexWriter indexWriter = new IndexWriter(cacheDir, new IndexWriterConfig(Version.LUCENE_41, englishAnalyzer). setOpenMode(IndexWriterConfig.OpenMode.CREATE)); Fails with CorruptedIndex subclass, IndexTooOldException (or something like that), even though the config would just replace the files. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571631#comment-13571631 ] Erik Hatcher commented on SOLR-3251: bq. Keeping the DOM around would also allow for round-tripping comments and whitespace... IMO - The XMLness of the current Solr schema needs to be isolated to only one optional way of constructing an IndexSchema instance. We want less XML rather than more. (for example, it should be possible to have a relational database that contains a model of a schema and load it that way) dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Attachments: SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3251) dynamically add field to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571711#comment-13571711
]
Steve Rowe commented on SOLR-3251:
--
{quote}
IMO - The XMLness of the current Solr schema needs to be isolated to only one
optional way of constructing an IndexSchema instance. We want less XML rather
than more. (for example, it should be possible to have a relational database
that contains a model of a schema and load it that way)
{quote}
Well, I don't want to change the entire world all at once here :). And the
serialized representation in Zookeeper won't be a relational DB (dump), but I
suppose it could be JSON or YAML instead of XML. AFAICT, YAML isn't used in
Solr anywhere. And JSON doesn't support comments, but I think documentation
could be included as a {{documentation:comment}} pair at the appropriate
level, similar to how W3C XML Schema syntax uses {{documentation}} within
{{annotation}}.
But I guess you're arguing against depending on an XML-specific intermediate
representation (the DOM)?
dynamically add field to schema
---
Key: SOLR-3251
URL: https://issues.apache.org/jira/browse/SOLR-3251
Project: Solr
Issue Type: New Feature
Reporter: Yonik Seeley
Attachments: SOLR-3251.patch
One related piece of functionality needed for SOLR-3250 is the ability to
dynamically add a field to the schema.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
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-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571713#comment-13571713 ] Erik Hatcher commented on SOLR-3251: bq. And the serialized representation in Zookeeper won't be a relational DB (dump), but I suppose it could be JSON or YAML instead of XML True, and it could also be broken down into individual keys rather than one big schema blog... such that an individual field is defined under a schema tree rather than a config file being stored in XML format. bq. But I guess you're arguing against depending on an XML-specific intermediate representation (the DOM)? Kinda, yeah, but I'm just thinking out loud here and just making sure we don't over XML things further. Regarding documentation: perhaps a field could be documented with a comment or description attribute. dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Attachments: SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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] [Comment Edited] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571713#comment-13571713 ] Erik Hatcher edited comment on SOLR-3251 at 2/5/13 8:57 PM: bq. And the serialized representation in Zookeeper won't be a relational DB (dump), but I suppose it could be JSON or YAML instead of XML True, and it could also be broken down into individual keys rather than one big schema blob... such that an individual field is defined under a schema tree rather than a config file being stored in XML format. bq. But I guess you're arguing against depending on an XML-specific intermediate representation (the DOM)? Kinda, yeah, but I'm just thinking out loud here and just making sure we don't over XML things further. Regarding documentation: perhaps a field could be documented with a comment or description attribute. was (Author: ehatcher): bq. And the serialized representation in Zookeeper won't be a relational DB (dump), but I suppose it could be JSON or YAML instead of XML True, and it could also be broken down into individual keys rather than one big schema blog... such that an individual field is defined under a schema tree rather than a config file being stored in XML format. bq. But I guess you're arguing against depending on an XML-specific intermediate representation (the DOM)? Kinda, yeah, but I'm just thinking out loud here and just making sure we don't over XML things further. Regarding documentation: perhaps a field could be documented with a comment or description attribute. dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Attachments: SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
Build failed in Jenkins: the_4547_machine_gun #2533
See http://fortyounce.servebeer.com/job/the_4547_machine_gun/2533/ -- [...truncated 9486 lines...] clover: compile-core: module-build.init: check-queries-uptodate: jar-queries: init: test: [echo] Building grouping... -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: ivy-availability-check: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: module-build.init: check-queries-uptodate: jar-queries: init: compile-test: [echo] Building grouping... ivy-availability-check: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: module-build.init: check-queries-uptodate: jar-queries: init: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: compile-core: compile-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: init: compile-lucene-core: compile-codecs: [echo] Building codecs... ivy-availability-check: [echo] Building codecs... ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: compile-core: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: common.compile-core: compile-core: common.compile-test: install-junit4-taskdef: validate: common.test: [mkdir] Created dir: http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/build/grouping/test [mkdir] Created dir: http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/build/grouping/test/temp [junit4:junit4] JUnit4 says g'day! Master seed: 49F4B3F0B539EE2E [junit4:junit4] Executing 6 suites with 4 JVMs. [junit4:junit4] [junit4:junit4] Started J1 PID(16082@beast). [junit4:junit4] Started J2 PID(16081@beast). [junit4:junit4] Started J0 PID(16079@beast). [junit4:junit4] Started J3 PID(16080@beast). [junit4:junit4] Suite: org.apache.lucene.search.grouping.AllGroupsCollectorTest [junit4:junit4] Completed on J3 in 0.86s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.grouping.GroupingSearchTest [junit4:junit4] Completed on J3 in 0.10s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.grouping.GroupFacetCollectorTest [junit4:junit4] Completed on J2 in 2.54s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.grouping.AllGroupHeadsCollectorTest [junit4:junit4] Completed on J1 in 3.73s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.grouping.DistinctValuesCollectorTest [junit4:junit4] Completed on J3 in 3.31s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.grouping.TestGrouping [junit4:junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestGrouping -Dtests.method=testRandom -Dtests.seed=49F4B3F0B539EE2E -Dtests.slow=true -Dtests.locale=pt_BR -Dtests.timezone=Asia/Aqtau -Dtests.file.encoding=UTF-8 [junit4:junit4] ERROR 5.36s J0 | TestGrouping.testRandom [junit4:junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException: 1 [junit4:junit4]at __randomizedtesting.SeedInfo.seed([49F4B3F0B539EE2E:3BB896FF0459585D]:0) [junit4:junit4]at org.apache.lucene.index.MultiDocValues$MultiSortedDocValues.lookupOrd(MultiDocValues.java:294) [junit4:junit4]at org.apache.lucene.index.SortedDocValues.get(SortedDocValues.java:66) [junit4:junit4]at org.apache.lucene.index.AssertingAtomicReader$AssertingSortedDocValues.get(AssertingAtomicReader.java:443) [junit4:junit4]at org.apache.lucene.queries.function.docvalues.DocTermsIndexDocValues$2.fillValue(DocTermsIndexDocValues.java:154) [junit4:junit4]at org.apache.lucene.search.grouping.function.FunctionFirstPassGroupingCollector.getDocGroupValue(FunctionFirstPassGroupingCollector.java:66) [junit4:junit4]at org.apache.lucene.search.grouping.function.FunctionFirstPassGroupingCollector.getDocGroupValue(FunctionFirstPassGroupingCollector.java:36) [junit4:junit4]at org.apache.lucene.search.grouping.AbstractFirstPassGroupingCollector.collect(AbstractFirstPassGroupingCollector.java:179) [junit4:junit4]at org.apache.lucene.search.Scorer.score(Scorer.java:64) [junit4:junit4]at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:598) [junit4:junit4]at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:302) [junit4:junit4]at
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #760: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/760/ 2 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.org.apache.solr.cloud.ChaosMonkeySafeLeaderTest Error Message: 3 threads leaked from SUITE scope at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest: 1) Thread[id=3442, name=Thread-1101-EventThread, state=BLOCKED, group=TGRP-ChaosMonkeySafeLeaderTest] at org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:71) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:519) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495) 2) Thread[id=3798, name=Thread-1101-EventThread, state=TIMED_WAITING, group=TGRP-ChaosMonkeySafeLeaderTest] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkController.waitForLeaderToSeeDownState(ZkController.java:1241) at org.apache.solr.cloud.ZkController.registerAllCoresAsDown(ZkController.java:304) at org.apache.solr.cloud.ZkController.access$100(ZkController.java:85) at org.apache.solr.cloud.ZkController$1.command(ZkController.java:193) at org.apache.solr.common.cloud.ConnectionManager$1.update(ConnectionManager.java:117) at org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:46) at org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:91) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:519) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495) 3) Thread[id=3345, name=Thread-1101-EventThread, state=TIMED_WAITING, group=TGRP-ChaosMonkeySafeLeaderTest] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkController.waitForLeaderToSeeDownState(ZkController.java:1241) at org.apache.solr.cloud.ZkController.registerAllCoresAsDown(ZkController.java:304) at org.apache.solr.cloud.ZkController.access$100(ZkController.java:85) at org.apache.solr.cloud.ZkController$1.command(ZkController.java:193) at org.apache.solr.common.cloud.ConnectionManager$1.update(ConnectionManager.java:117) at org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:46) at org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:91) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:519) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 3 threads leaked from SUITE scope at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest: 1) Thread[id=3442, name=Thread-1101-EventThread, state=BLOCKED, group=TGRP-ChaosMonkeySafeLeaderTest] at org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:71) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:519) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495) 2) Thread[id=3798, name=Thread-1101-EventThread, state=TIMED_WAITING, group=TGRP-ChaosMonkeySafeLeaderTest] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkController.waitForLeaderToSeeDownState(ZkController.java:1241) at org.apache.solr.cloud.ZkController.registerAllCoresAsDown(ZkController.java:304) at org.apache.solr.cloud.ZkController.access$100(ZkController.java:85) at org.apache.solr.cloud.ZkController$1.command(ZkController.java:193) at org.apache.solr.common.cloud.ConnectionManager$1.update(ConnectionManager.java:117) at org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:46) at org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:91) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:519) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495) 3) Thread[id=3345, name=Thread-1101-EventThread, state=TIMED_WAITING, group=TGRP-ChaosMonkeySafeLeaderTest] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkController.waitForLeaderToSeeDownState(ZkController.java:1241) at org.apache.solr.cloud.ZkController.registerAllCoresAsDown(ZkController.java:304) at org.apache.solr.cloud.ZkController.access$100(ZkController.java:85) at org.apache.solr.cloud.ZkController$1.command(ZkController.java:193) at org.apache.solr.common.cloud.ConnectionManager$1.update(ConnectionManager.java:117) at org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:46) at org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:91) at
Jenkins build is back to normal : the_4547_machine_gun #2534
See http://fortyounce.servebeer.com/job/the_4547_machine_gun/2534/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4718) Default field in query syntax documentation has confusing error
[ https://issues.apache.org/jira/browse/LUCENE-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hayden Muhl updated LUCENE-4718: Fix Version/s: (was: 4.0.1) 4.2 Default field in query syntax documentation has confusing error --- Key: LUCENE-4718 URL: https://issues.apache.org/jira/browse/LUCENE-4718 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 4.0 Reporter: Hayden Muhl Priority: Trivial Labels: documentation Fix For: 4.2 Attachments: SOLR-4357.patch Original Estimate: 5m Remaining Estimate: 5m The explanation of default search fields uses two different queries that are supposed to be semantically the same, but the query text changes between the two examples. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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
Build failed in Jenkins: the_4547_machine_gun #2537
See http://fortyounce.servebeer.com/job/the_4547_machine_gun/2537/ -- [...truncated 6648 lines...] -clover.load: -clover.classpath: -clover.setup: clover: ivy-availability-check: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: compile-test: [echo] Building analyzers-icu... check-analyzers-common-uptodate: jar-analyzers-common: ivy-availability-check: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: common.compile-core: compile-core: compile-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: init: compile-lucene-core: compile-codecs: [echo] Building codecs... ivy-availability-check: [echo] Building codecs... ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: compile-core: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: common.compile-core: compile-core: common.compile-test: install-junit4-taskdef: validate: common.test: [mkdir] Created dir: http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/build/analysis/icu/test [mkdir] Created dir: http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/build/analysis/icu/test/temp [junit4:junit4] JUnit4 says hello! Master seed: BF11BB2C01FE7110 [junit4:junit4] Executing 13 suites with 4 JVMs. [junit4:junit4] [junit4:junit4] Started J2 PID(12776@beast). [junit4:junit4] Started J0 PID(12770@beast). [junit4:junit4] Started J1 PID(12777@beast). [junit4:junit4] Started J3 PID(12771@beast). [junit4:junit4] Suite: org.apache.lucene.analysis.icu.TestICUNormalizer2FilterFactory [junit4:junit4] Completed on J3 in 0.76s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.analysis.icu.TestICUTransformFilterFactory [junit4:junit4] Completed on J1 in 1.47s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.analysis.icu.segmentation.TestICUTokenizerFactory [junit4:junit4] Completed on J0 in 1.24s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.analysis.icu.segmentation.TestWithCJKBigramFilter [junit4:junit4] Completed on J2 in 1.20s, 12 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.analysis.icu.segmentation.TestLaoBreakIterator [junit4:junit4] Completed on J2 in 0.09s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.analysis.icu.segmentation.TestCharArrayIterator [junit4:junit4] Completed on J2 in 0.07s, 7 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.analysis.icu.TestICUNormalizer2Filter [junit4:junit4] Completed on J3 in 0.66s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.analysis.icu.TestICUFoldingFilter [junit4:junit4] Completed on J2 in 0.67s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.analysis.icu.TestICUFoldingFilterFactory [junit4:junit4] Completed on J2 in 0.11s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.analysis.icu.segmentation.TestICUTokenizer [junit4:junit4] Completed on J0 in 1.92s, 30 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.collation.TestICUCollationKeyAnalyzer [junit4:junit4] Completed on J3 in 1.62s, 5 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.collation.TestICUCollationDocValuesField [junit4:junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestICUCollationDocValuesField -Dtests.method=testRanges -Dtests.seed=BF11BB2C01FE7110 -Dtests.slow=true -Dtests.locale=ru -Dtests.timezone=Asia/Ulan_Bator -Dtests.file.encoding=ISO-8859-1 [junit4:junit4] ERROR 0.71s J2 | TestICUCollationDocValuesField.testRanges [junit4:junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException: 1 [junit4:junit4]at __randomizedtesting.SeedInfo.seed([BF11BB2C01FE7110:62A8CAE36EBC27F6]:0) [junit4:junit4]at org.apache.lucene.index.MultiDocValues$MultiSortedDocValues.lookupOrd(MultiDocValues.java:294) [junit4:junit4]at org.apache.lucene.index.SortedDocValues.lookupTerm(SortedDocValues.java:103) [junit4:junit4]at org.apache.lucene.search.FieldCacheRangeFilter$2.getDocIdSet(FieldCacheRangeFilter.java:151) [junit4:junit4]at org.apache.lucene.search.ConstantScoreQuery$ConstantWeight.scorer(ConstantScoreQuery.java:131) [junit4:junit4]at
Jenkins build is back to normal : the_4547_machine_gun #2538
See http://fortyounce.servebeer.com/job/the_4547_machine_gun/2538/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS-MAVEN] Lucene-Solr-Maven-trunk #760: POMs out of sync
Committing a 'bail early on closed' - these threads are in a retry loop that takes a while. - Mark On Feb 5, 2013, at 4:47 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/760/ 2 tests failed. FAILED: org.apache.solr.cloud.ChaosMonkeySafeLeaderTest.org.apache.solr.cloud.ChaosMonkeySafeLeaderTest Error Message: 3 threads leaked from SUITE scope at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest: 1) Thread[id=3442, name=Thread-1101-EventThread, state=BLOCKED, group=TGRP-ChaosMonkeySafeLeaderTest] at org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:71) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:519) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495)2) Thread[id=3798, name=Thread-1101-EventThread, state=TIMED_WAITING, group=TGRP-ChaosMonkeySafeLeaderTest] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkController.waitForLeaderToSeeDownState(ZkController.java:1241) at org.apache.solr.cloud.ZkController.registerAllCoresAsDown(ZkController.java:304) at org.apache.solr.cloud.ZkController.access$100(ZkController.java:85) at org.apache.solr.cloud.ZkController$1.command(ZkController.java:193) at org.apache.solr.common.cloud.ConnectionManager$1.update(ConnectionManager.java:117) at org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:46) at org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:91) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:519) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495)3) Thread[id=3345, name=Thread-1101-EventThread, state=TIMED_WAITING, group=TGRP-ChaosMonkeySafeLeaderTest] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkController.waitForLeaderToSeeDownState(ZkController.java:1241) at org.apache.solr.cloud.ZkController.registerAllCoresAsDown(ZkController.java:304) at org.apache.solr.cloud.ZkController.access$100(ZkController.java:85) at org.apache.solr.cloud.ZkController$1.command(ZkController.java:193) at org.apache.solr.common.cloud.ConnectionManager$1.update(ConnectionManager.java:117) at org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:46) at org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:91) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:519) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495) Stack Trace: com.carrotsearch.randomizedtesting.ThreadLeakError: 3 threads leaked from SUITE scope at org.apache.solr.cloud.ChaosMonkeySafeLeaderTest: 1) Thread[id=3442, name=Thread-1101-EventThread, state=BLOCKED, group=TGRP-ChaosMonkeySafeLeaderTest] at org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:71) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:519) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495) 2) Thread[id=3798, name=Thread-1101-EventThread, state=TIMED_WAITING, group=TGRP-ChaosMonkeySafeLeaderTest] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkController.waitForLeaderToSeeDownState(ZkController.java:1241) at org.apache.solr.cloud.ZkController.registerAllCoresAsDown(ZkController.java:304) at org.apache.solr.cloud.ZkController.access$100(ZkController.java:85) at org.apache.solr.cloud.ZkController$1.command(ZkController.java:193) at org.apache.solr.common.cloud.ConnectionManager$1.update(ConnectionManager.java:117) at org.apache.solr.common.cloud.DefaultConnectionStrategy.reconnect(DefaultConnectionStrategy.java:46) at org.apache.solr.common.cloud.ConnectionManager.process(ConnectionManager.java:91) at org.apache.zookeeper.ClientCnxn$EventThread.processEvent(ClientCnxn.java:519) at org.apache.zookeeper.ClientCnxn$EventThread.run(ClientCnxn.java:495) 3) Thread[id=3345, name=Thread-1101-EventThread, state=TIMED_WAITING, group=TGRP-ChaosMonkeySafeLeaderTest] at java.lang.Thread.sleep(Native Method) at org.apache.solr.cloud.ZkController.waitForLeaderToSeeDownState(ZkController.java:1241) at org.apache.solr.cloud.ZkController.registerAllCoresAsDown(ZkController.java:304) at org.apache.solr.cloud.ZkController.access$100(ZkController.java:85) at org.apache.solr.cloud.ZkController$1.command(ZkController.java:193) at
Build failed in Jenkins: the_4547_machine_gun #2539
See http://fortyounce.servebeer.com/job/the_4547_machine_gun/2539/ -- [...truncated 9481 lines...] -clover.load: -clover.classpath: -clover.setup: clover: compile-core: module-build.init: check-queries-uptodate: jar-queries: init: test: [echo] Building grouping... -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: ivy-availability-check: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: module-build.init: check-queries-uptodate: jar-queries: init: compile-test: [echo] Building grouping... ivy-availability-check: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: module-build.init: check-queries-uptodate: jar-queries: init: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: compile-core: compile-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: init: compile-lucene-core: compile-codecs: [echo] Building codecs... ivy-availability-check: [echo] Building codecs... ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: compile-core: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: common.compile-core: compile-core: common.compile-test: install-junit4-taskdef: validate: common.test: [mkdir] Created dir: http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/build/grouping/test [mkdir] Created dir: http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/build/grouping/test/temp [junit4:junit4] JUnit4 says ᐊᐃ! Master seed: D0AFF57204B2AA3A [junit4:junit4] Executing 6 suites with 4 JVMs. [junit4:junit4] [junit4:junit4] Started J3 PID(28070@beast). [junit4:junit4] Started J1 PID(28071@beast). [junit4:junit4] Started J0 PID(28069@beast). [junit4:junit4] Started J2 PID(28076@beast). [junit4:junit4] Suite: org.apache.lucene.search.grouping.GroupingSearchTest [junit4:junit4] Completed on J3 in 0.85s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.grouping.GroupFacetCollectorTest [junit4:junit4] 2 NOTE: reproduce with: ant test -Dtestcase=GroupFacetCollectorTest -Dtests.method=testRandom -Dtests.seed=D0AFF57204B2AA3A -Dtests.slow=true -Dtests.locale=ar_KW -Dtests.timezone=Indian/Mahe -Dtests.file.encoding=UTF-8 [junit4:junit4] ERROR 1.79s J2 | GroupFacetCollectorTest.testRandom [junit4:junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException: 1 [junit4:junit4]at __randomizedtesting.SeedInfo.seed([D0AFF57204B2AA3A:A2E3D07DB5D21C49]:0) [junit4:junit4]at org.apache.lucene.index.MultiDocValues$MultiSortedDocValues.lookupOrd(MultiDocValues.java:294) [junit4:junit4]at org.apache.lucene.index.SortedDocValues.lookupTerm(SortedDocValues.java:103) [junit4:junit4]at org.apache.lucene.search.grouping.term.TermGroupFacetCollector$SV.setNextReader(TermGroupFacetCollector.java:153) [junit4:junit4]at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:595) [junit4:junit4]at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:302) [junit4:junit4]at org.apache.lucene.search.grouping.GroupFacetCollectorTest.testRandom(GroupFacetCollectorTest.java:379) [junit4:junit4]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4:junit4]at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [junit4:junit4]at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit4:junit4]at java.lang.reflect.Method.invoke(Method.java:601) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) [junit4:junit4]at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) [junit4:junit4]at
Jenkins build is back to normal : the_4547_machine_gun #2540
See http://fortyounce.servebeer.com/job/the_4547_machine_gun/2540/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4718) Default field in query syntax documentation has confusing error
[ https://issues.apache.org/jira/browse/LUCENE-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571852#comment-13571852 ] Commit Tag Bot commented on LUCENE-4718: [trunk commit] Adrien Grand http://svn.apache.org/viewvc?view=revisionrevision=1442786 LUCENE-4718: Fix documentation of oal.queryparser.classic. Default field in query syntax documentation has confusing error --- Key: LUCENE-4718 URL: https://issues.apache.org/jira/browse/LUCENE-4718 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 4.0 Reporter: Hayden Muhl Priority: Trivial Labels: documentation Fix For: 4.2 Attachments: SOLR-4357.patch Original Estimate: 5m Remaining Estimate: 5m The explanation of default search fields uses two different queries that are supposed to be semantically the same, but the query text changes between the two examples. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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: Build failed in Jenkins: the_4547_machine_gun #2539
I committed a fix for these. slow-wrappers within slow-wrappers On Tue, Feb 5, 2013 at 5:14 PM, Charlie Cron hudsonsevilt...@gmail.com wrote: See http://fortyounce.servebeer.com/job/the_4547_machine_gun/2539/ -- [...truncated 9481 lines...] -clover.load: -clover.classpath: -clover.setup: clover: compile-core: module-build.init: check-queries-uptodate: jar-queries: init: test: [echo] Building grouping... -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: ivy-availability-check: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: module-build.init: check-queries-uptodate: jar-queries: init: compile-test: [echo] Building grouping... ivy-availability-check: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: module-build.init: check-queries-uptodate: jar-queries: init: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: compile-core: compile-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: init: compile-lucene-core: compile-codecs: [echo] Building codecs... ivy-availability-check: [echo] Building codecs... ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: compile-core: -clover.disable: -clover.load: -clover.classpath: -clover.setup: clover: common.compile-core: compile-core: common.compile-test: install-junit4-taskdef: validate: common.test: [mkdir] Created dir: http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/build/grouping/test [mkdir] Created dir: http://fortyounce.servebeer.com/job/the_4547_machine_gun/ws/build/grouping/test/temp [junit4:junit4] JUnit4 says ᐊᐃ! Master seed: D0AFF57204B2AA3A [junit4:junit4] Executing 6 suites with 4 JVMs. [junit4:junit4] [junit4:junit4] Started J3 PID(28070@beast). [junit4:junit4] Started J1 PID(28071@beast). [junit4:junit4] Started J0 PID(28069@beast). [junit4:junit4] Started J2 PID(28076@beast). [junit4:junit4] Suite: org.apache.lucene.search.grouping.GroupingSearchTest [junit4:junit4] Completed on J3 in 0.85s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.grouping.GroupFacetCollectorTest [junit4:junit4] 2 NOTE: reproduce with: ant test -Dtestcase=GroupFacetCollectorTest -Dtests.method=testRandom -Dtests.seed=D0AFF57204B2AA3A -Dtests.slow=true -Dtests.locale=ar_KW -Dtests.timezone=Indian/Mahe -Dtests.file.encoding=UTF-8 [junit4:junit4] ERROR 1.79s J2 | GroupFacetCollectorTest.testRandom [junit4:junit4] Throwable #1: java.lang.ArrayIndexOutOfBoundsException: 1 [junit4:junit4]at __randomizedtesting.SeedInfo.seed([D0AFF57204B2AA3A:A2E3D07DB5D21C49]:0) [junit4:junit4]at org.apache.lucene.index.MultiDocValues$MultiSortedDocValues.lookupOrd(MultiDocValues.java:294) [junit4:junit4]at org.apache.lucene.index.SortedDocValues.lookupTerm(SortedDocValues.java:103) [junit4:junit4]at org.apache.lucene.search.grouping.term.TermGroupFacetCollector$SV.setNextReader(TermGroupFacetCollector.java:153) [junit4:junit4]at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:595) [junit4:junit4]at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:302) [junit4:junit4]at org.apache.lucene.search.grouping.GroupFacetCollectorTest.testRandom(GroupFacetCollectorTest.java:379) [junit4:junit4]at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4:junit4]at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [junit4:junit4]at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit4:junit4]at java.lang.reflect.Method.invoke(Method.java:601) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) [junit4:junit4]at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) [junit4:junit4]
[jira] [Closed] (LUCENE-4718) Default field in query syntax documentation has confusing error
[ https://issues.apache.org/jira/browse/LUCENE-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Adrien Grand closed LUCENE-4718. Resolution: Fixed Assignee: Adrien Grand Committed! Thanks Hayden! Default field in query syntax documentation has confusing error --- Key: LUCENE-4718 URL: https://issues.apache.org/jira/browse/LUCENE-4718 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 4.0 Reporter: Hayden Muhl Assignee: Adrien Grand Priority: Trivial Labels: documentation Fix For: 4.2 Attachments: SOLR-4357.patch Original Estimate: 5m Remaining Estimate: 5m The explanation of default search fields uses two different queries that are supposed to be semantically the same, but the query text changes between the two examples. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-4718) Default field in query syntax documentation has confusing error
[ https://issues.apache.org/jira/browse/LUCENE-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571880#comment-13571880 ] Commit Tag Bot commented on LUCENE-4718: [branch_4x commit] Adrien Grand http://svn.apache.org/viewvc?view=revisionrevision=1442790 LUCENE-4718: Fix documentation of oal.queryparser.classic (merged from r1442786). Default field in query syntax documentation has confusing error --- Key: LUCENE-4718 URL: https://issues.apache.org/jira/browse/LUCENE-4718 Project: Lucene - Core Issue Type: Bug Components: core/queryparser Affects Versions: 4.0 Reporter: Hayden Muhl Assignee: Adrien Grand Priority: Trivial Labels: documentation Fix For: 4.2 Attachments: SOLR-4357.patch Original Estimate: 5m Remaining Estimate: 5m The explanation of default search fields uses two different queries that are supposed to be semantically the same, but the query text changes between the two examples. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_10) - Build # 4146 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4146/ Java: 32bit/jdk1.7.0_10 -server -XX:+UseG1GC All tests passed Build Log: [...truncated 30630 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:305: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:68: javax.script.ScriptException: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:138) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108) at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81) at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103) at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67) at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:302) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Caused by: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:335) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:132) ... 40 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16$PropFetchHandler.handleError(SVNWCClient16.java:4145) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:790) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:757) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doGetLocalProperty(SVNWCClient16.java:3881) at
[jira] [Commented] (SOLR-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571978#comment-13571978 ] Erick Erickson commented on SOLR-3251: -- FWIW, I've seen situations in which the actual structure of schema.xml doesn't reflect what we usually think of as correct, i.e. I saw something like (going from memory) fields field.../field copyField/ field.../field /fields But since the DOM traversal just asks for all leaf nodes for some situations, this worked just fine. Something to keep in mind when thinking about this in terms of breaking existing installations. That said I don't think we should strain to preserve this behavior. FWIW, Erick dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Attachments: SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13571994#comment-13571994 ] Steve Rowe commented on SOLR-3251: -- bq. copyField ... DOM traversal Yeah, I saw that. I also noticed that the comment above the //copyField leaf-node-anywhere XPath says that the expression is /schema/copyField, and that both lines date back to Yonik's 2006 initial version :), so this flexibility is long-standing. dynamically add field to schema --- Key: SOLR-3251 URL: https://issues.apache.org/jira/browse/SOLR-3251 Project: Solr Issue Type: New Feature Reporter: Yonik Seeley Attachments: SOLR-3251.patch One related piece of functionality needed for SOLR-3250 is the ability to dynamically add a field to the schema. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-4.x-java7 - Build # 967 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-java7/967/ All tests passed Build Log: [...truncated 30546 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/build.xml:305: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/extra-targets.xml:68: javax.script.ScriptException: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:138) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108) at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81) at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103) at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67) at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:302) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Caused by: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:335) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:132) ... 40 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/tools/lib' is missing at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16$PropFetchHandler.handleError(SVNWCClient16.java:4145) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:790) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:757) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doGetLocalProperty(SVNWCClient16.java:3881)
[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.6.0_38) - Build # 4147 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4147/ Java: 64bit/jdk1.6.0_38 -XX:+UseParallelGC All tests passed Build Log: [...truncated 29916 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:305: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:68: javax.script.ScriptException: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:138) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:247) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108) at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81) at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103) at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67) at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:302) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Caused by: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:335) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:132) ... 40 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16$PropFetchHandler.handleError(SVNWCClient16.java:4145) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:790) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:757) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doGetLocalProperty(SVNWCClient16.java:3881) at
[jira] [Updated] (LUCENE-4547) DocValues field broken on large indexes
[
https://issues.apache.org/jira/browse/LUCENE-4547?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-4547:
Attachment: LUCENE-4547.patch
Applyable patch to trunk r1442822.
I think this is close: jenkins-blasted, benchmarked, beefed up tests and added
many new ones, several codecs with different tradeoffs, per-field
configuration, 4.0 file format compat, more efficient 4.2 format, and so on.
DocValues field broken on large indexes
---
Key: LUCENE-4547
URL: https://issues.apache.org/jira/browse/LUCENE-4547
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
Fix For: 4.2, 5.0
Attachments: LUCENE-4547.patch, test.patch
I tried to write a test to sanity check LUCENE-4536 (first running against
svn revision 1406416, before the change).
But i found docvalues is already broken here for large indexes that have a
PackedLongDocValues field:
{code}
final int numDocs = 5;
for (int i = 0; i numDocs; ++i) {
if (i == 0) {
field.setLongValue(0L); // force 32bit deltas
} else {
field.setLongValue(133L);
}
w.addDocument(doc);
}
w.forceMerge(1);
w.close();
dir.close(); // checkindex
{code}
{noformat}
[junit4:junit4] 2 WARNING: Uncaught exception in thread: Thread[Lucene
Merge Thread #0,6,TGRP-Test2GBDocValues]
[junit4:junit4] 2 org.apache.lucene.index.MergePolicy$MergeException:
java.lang.ArrayIndexOutOfBoundsException: -65536
[junit4:junit4] 2 at
__randomizedtesting.SeedInfo.seed([5DC54DB14FA5979]:0)
[junit4:junit4] 2 at
org.apache.lucene.index.ConcurrentMergeScheduler.handleMergeException(ConcurrentMergeScheduler.java:535)
[junit4:junit4] 2 at
org.apache.lucene.index.ConcurrentMergeScheduler$MergeThread.run(ConcurrentMergeScheduler.java:508)
[junit4:junit4] 2 Caused by: java.lang.ArrayIndexOutOfBoundsException:
-65536
[junit4:junit4] 2 at
org.apache.lucene.util.ByteBlockPool.deref(ByteBlockPool.java:305)
[junit4:junit4] 2 at
org.apache.lucene.codecs.lucene40.values.FixedStraightBytesImpl$FixedBytesWriterBase.set(FixedStraightBytesImpl.java:115)
[junit4:junit4] 2 at
org.apache.lucene.codecs.lucene40.values.PackedIntValues$PackedIntsWriter.writePackedInts(PackedIntValues.java:109)
[junit4:junit4] 2 at
org.apache.lucene.codecs.lucene40.values.PackedIntValues$PackedIntsWriter.finish(PackedIntValues.java:80)
[junit4:junit4] 2 at
org.apache.lucene.codecs.DocValuesConsumer.merge(DocValuesConsumer.java:130)
[junit4:junit4] 2 at
org.apache.lucene.codecs.PerDocConsumer.merge(PerDocConsumer.java:65)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-4406) RawResponseWriter - doesn't use the configured base writer.
Steve Davids created SOLR-4406: -- Summary: RawResponseWriter - doesn't use the configured base writer. Key: SOLR-4406 URL: https://issues.apache.org/jira/browse/SOLR-4406 Project: Solr Issue Type: Bug Components: Response Writers Affects Versions: 4.0 Reporter: Steve Davids The RawResponseWriter accepts a configuration value for a base ResponseWriter if no ContentStream can be detected. The line of code is commented out that would allow this secondary response writer to work. It would be great to uncomment the line and provide an OutputStreamWriter as the writer argument. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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: Wild card support when stemmers are added
Hi, You have to separate options where you keep both accessorising and accessorise at index. 1) https://issues.apache.org/jira/browse/SOLR-3231 2) Create a un-stemmed field and run wildcard queries against it too. --- On Tue, 2/5/13, msreddy.hi msreddy...@gmail.com wrote: From: msreddy.hi msreddy...@gmail.com Subject: Re: Wild card support when stemmers are added To: dev@lucene.apache.org Date: Tuesday, February 5, 2013, 11:40 AM Thanks Jack. I will look at the option of implementing work around. --Saida Reddy. -- View this message in context: http://lucene.472066.n3.nabble.com/Wild-card-support-when-stemmers-are-added-tp4038402p4038511.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4743) ComplexPhraseQuery highlight problem after rewriting using ComplexPhraseQuery.rewrite(IndexReader)
[ https://issues.apache.org/jira/browse/LUCENE-4743?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13572098#comment-13572098 ] Ahmet Arslan commented on LUCENE-4743: -- May be highlighter works without re-write after https://issues.apache.org/jira/browse/LUCENE-4728? ComplexPhraseQuery highlight problem after rewriting using ComplexPhraseQuery.rewrite(IndexReader) -- Key: LUCENE-4743 URL: https://issues.apache.org/jira/browse/LUCENE-4743 Project: Lucene - Core Issue Type: Bug Components: core/search, modules/queryparser Affects Versions: 3.6 Reporter: Jason Nacional Labels: complexqueryparser, newbie, queryparser Just want to ask an assistance using ComplexPhraseQuery. I mean, when it comes to highlighting the hits are not correct. I also started using ComplexPhraseQueryParser to support complex proximity searches. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators 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: [JENKINS] Lucene-Solr-Tests-4.x-java7 - Build # 967 - Failure
I had this same issue locally when svn updating. i manually did 'svn update' on the workspace... hopefully this fixes it? On Tue, Feb 5, 2013 at 8:12 PM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-java7/967/ All tests passed Build Log: [...truncated 30546 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/build.xml:305: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/extra-targets.xml:68: javax.script.ScriptException: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:138) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108) at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81) at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103) at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67) at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:302) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Caused by: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:335) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:132) ... 40 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-java7/lucene/tools/lib' is missing at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16$PropFetchHandler.handleError(SVNWCClient16.java:4145)
[JENKINS] Lucene-Solr-4.x-Windows (64bit/jdk1.6.0_38) - Build # 2499 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Windows/2499/ Java: 64bit/jdk1.6.0_38 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 29902 lines...] BUILD FAILED C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\build.xml:305: The following error occurred while executing this line: C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\extra-targets.xml:68: javax.script.ScriptException: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory 'C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\tools\lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:138) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:247) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108) at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81) at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103) at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67) at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:302) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Caused by: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory 'C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\tools\lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:335) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:132) ... 40 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory 'C:\Users\JenkinsSlave\workspace\Lucene-Solr-4.x-Windows\lucene\tools\lib' is missing at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16$PropFetchHandler.handleError(SVNWCClient16.java:4145) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:790) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:757) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doGetLocalProperty(SVNWCClient16.java:3881) at
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.6.0_38) - Build # 4149 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4149/ Java: 32bit/jdk1.6.0_38 -client -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 29858 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:305: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:68: javax.script.ScriptException: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:138) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:247) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108) at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81) at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103) at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67) at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:302) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Caused by: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:335) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:132) ... 40 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16$PropFetchHandler.handleError(SVNWCClient16.java:4145) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:790) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:757) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doGetLocalProperty(SVNWCClient16.java:3881) at
[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_10) - Build # 4150 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4150/ Java: 64bit/jdk1.7.0_10 -XX:+UseSerialGC All tests passed Build Log: [...truncated 30543 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:305: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:68: javax.script.ScriptException: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:138) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108) at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81) at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103) at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67) at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:302) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Caused by: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:335) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:132) ... 40 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16$PropFetchHandler.handleError(SVNWCClient16.java:4145) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:790) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:757) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doGetLocalProperty(SVNWCClient16.java:3881) at
[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 177 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/177/ Java: 64bit/jdk1.7.0 -XX:+UseParallelGC All tests passed Build Log: [...truncated 30543 lines...] BUILD FAILED /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/build.xml:305: The following error occurred while executing this line: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/extra-targets.xml:68: javax.script.ScriptException: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:138) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108) at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81) at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103) at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67) at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:302) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Caused by: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:335) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:132) ... 40 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-4.x-MacOSX/lucene/tools/lib' is missing at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16$PropFetchHandler.handleError(SVNWCClient16.java:4145) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:790) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:757) at
[JENKINS] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_10) - Build # 4151 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/4151/ Java: 64bit/jdk1.7.0_10 -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 30548 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:305: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/extra-targets.xml:68: javax.script.ScriptException: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:138) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108) at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81) at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103) at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67) at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:302) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Caused by: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:335) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:132) ... 40 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/lib' is missing at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16$PropFetchHandler.handleError(SVNWCClient16.java:4145) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:790) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:757) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doGetLocalProperty(SVNWCClient16.java:3881) at
[JENKINS] Lucene-Solr-Tests-4.x-Java6 - Build # 1313 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-Java6/1313/ All tests passed Build Log: [...truncated 29966 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/build.xml:305: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/extra-targets.xml:68: javax.script.ScriptException: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:138) at javax.script.AbstractScriptEngine.eval(AbstractScriptEngine.java:264) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.tools.ant.util.ReflectUtil.invoke(ReflectUtil.java:108) at org.apache.tools.ant.util.ReflectWrapper.invoke(ReflectWrapper.java:81) at org.apache.tools.ant.util.optional.JavaxScriptRunner.evaluateScript(JavaxScriptRunner.java:103) at org.apache.tools.ant.util.optional.JavaxScriptRunner.executeScript(JavaxScriptRunner.java:67) at org.apache.tools.ant.taskdefs.optional.Script.execute(Script.java:52) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:302) at org.apache.tools.ant.taskdefs.SubAnt.execute(SubAnt.java:221) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.Target.execute(Target.java:390) at org.apache.tools.ant.Target.performTasks(Target.java:411) at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1399) at org.apache.tools.ant.Project.executeTarget(Project.java:1368) at org.apache.tools.ant.helper.DefaultExecutor.executeTargets(DefaultExecutor.java:41) at org.apache.tools.ant.Project.executeTargets(Project.java:1251) at org.apache.tools.ant.Main.runBuild(Main.java:809) at org.apache.tools.ant.Main.startAnt(Main.java:217) at org.apache.tools.ant.launch.Launcher.run(Launcher.java:280) at org.apache.tools.ant.launch.Launcher.main(Launcher.java:109) Caused by: javax.script.ScriptException: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/tools/lib' is missing at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:335) at org.codehaus.groovy.jsr223.GroovyScriptEngineImpl.eval(GroovyScriptEngineImpl.java:132) ... 40 more Caused by: org.tmatesoft.svn.core.SVNException: svn: E155005: Directory '/usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-4.x-Java6/lucene/tools/lib' is missing at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16$PropFetchHandler.handleError(SVNWCClient16.java:4145) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:790) at org.tmatesoft.svn.core.internal.wc.admin.SVNWCAccess.walkEntries(SVNWCAccess.java:757) at org.tmatesoft.svn.core.internal.wc16.SVNWCClient16.doGetLocalProperty(SVNWCClient16.java:3881)
