Re: Problem using TrecTopicsReader()
On Aug 6, 2013, at 10:36, Abhishek Gupta abhi.bansa...@gmail.com wrote: Hi, I have a problem using TrecTopicsReader which I have already asked on #lucene IRC but got no reply till yesterday. I also post it on SO( http://stackoverflow.com/questions/18054649/bufferedreader-in-pylucne). The problem is completely explained on SO. In the PyLucene Makefile find the jcc invocation and add java.io.BufferedReader to the long command line (don't forget the ending \ as needed) and rebuild PyLucene. Andi.. Please Help!! Thanking You Abhishek Gupta, 9416106204, 9624799165
Re: Problem using TrecTopicsReader()
On Aug 6, 2013, at 21:17, Abhishek Gupta abhi.bansa...@gmail.com wrote:
Hi,
Sorry for asking again, but I got another error.
After including the all the java libraries I want in jcc. I wrote code for
Trec Evaluation. While running it I got the error that `there is no
bechmark module `. So I modified the Makefile to compile and install
benchmark jar also.
But, while compiling the compiling pylucene I am getting the following
error:
-
BUILD SUCCESSFUL
Total time: 1 second
ICU not installed
/usr/bin/python -m jcc --shared --jar
lucene-java-4.3.0/lucene/build/core/lucene-core-4.3.0.jar --jar
lucene-java-4.3.0/lucene/build/analysis/common/lucene-analyzers-common-4.3.0.jar
--jar lucene-java-4.3.0/lucene/build/benchmark/lucene-benchmark-4.3.0.jar
--jar lucene-java-4.3.0/lucene/build/memory/lucene-memory-4.3.0.jar --jar
lucene-java-4.3.0/lucene/build/highlighter/lucene-highlighter-4.3.0.jar
--jar build/jar/extensions.jar --jar
lucene-java-4.3.0/lucene/build/queries/lucene-queries-4.3.0.jar --jar
lucene-java-4.3.0/lucene/build/queryparser/lucene-queryparser-4.3.0.jar
--jar lucene-java-4.3.0/lucene/build/sandbox/lucene-sandbox-4.3.0.jar --jar
lucene-java-4.3.0/lucene/build/grouping/lucene-grouping-4.3.0.jar --jar
lucene-java-4.3.0/lucene/build/join/lucene-join-4.3.0.jar --jar
lucene-java-4.3.0/lucene/build/facet/lucene-facet-4.3.0.jar --jar
lucene-java-4.3.0/lucene/build/suggest/lucene-suggest-4.3.0.jar
--use_full_names --package java.lang java.lang.System java.lang.Runtime
--package java.util java.util.Arrays java.util.Collections
java.util.HashMap java.util.HashSet java.util.TreeSet
java.lang.IllegalStateException java.lang.IndexOutOfBoundsException
java.util.NoSuchElementException java.text.SimpleDateFormat
java.text.DecimalFormat java.text.Collator --package java.util.concurrent
java.util.concurrent.Executors --package java.util.regex --package
java.iojava.io.StringReader java.io.InputStreamReader
java.io.FileInputStream
java.io.BufferedReader java.io.FileReader java.io.PrintWriter --exclude
org.apache.lucene.sandbox.queries.regex.JakartaRegexpCapabilities --exclude
org.apache.regexp.RegexpTunnel --python lucene --mapping
org.apache.lucene.document.Document
'get:(Ljava/lang/String;)Ljava/lang/String;' --mapping java.util.Properties
'getProperty:(Ljava/lang/String;)Ljava/lang/String;' --sequence
java.util.AbstractList 'size:()I' 'get:(I)Ljava/lang/Object;'
org.apache.lucene.index.IndexWriter:getReader --version 4.3.0 --module
python/collections.py --module python/ICUNormalizer2Filter.py --module
python/ICUFoldingFilter.py --module python/ICUTransformFilter.py --files 8
--build
While loading org/apache/lucene/benchmark/byTask/utils/StreamUtils
Traceback (most recent call last):
File /usr/lib/python2.7/runpy.py, line 162, in _run_module_as_main
__main__, fname, loader, pkg_name)
File /usr/lib/python2.7/runpy.py, line 72, in _run_code
exec code in run_globals
File
/usr/local/lib/python2.7/dist-packages/JCC-2.16-py2.7-linux-x86_64.egg/jcc/__main__.py,
line 107, in module
cpp.jcc(sys.argv)
File
/usr/local/lib/python2.7/dist-packages/JCC-2.16-py2.7-linux-x86_64.egg/jcc/cpp.py,
line 583, in jcc
cls = findClass(className.replace('.', '/'))
File
/usr/local/lib/python2.7/dist-packages/JCC-2.16-py2.7-linux-x86_64.egg/jcc/cpp.py,
line 73, in findClass
cls = _findClass(className)
jcc.cpp.JavaError: java.lang.NoClassDefFoundError:
org/apache/commons/compress/compressors/CompressorException
Java stacktrace:
java.lang.NoClassDefFoundError:
org/apache/commons/compress/compressors/CompressorException
at
org.apache.lucene.benchmark.byTask.utils.StreamUtils.clinit(StreamUtils.java:77)
Caused by: java.lang.ClassNotFoundException:
org.apache.commons.compress.compressors.CompressorException
at java.net.URLClassLoader$1.run(URLClassLoader.java:366)
at java.net.URLClassLoader$1.run(URLClassLoader.java:355)
at java.security.AccessController.doPrivileged(Native Method)
at java.net.URLClassLoader.findClass(URLClassLoader.java:354)
at java.lang.ClassLoader.loadClass(ClassLoader.java:424)
at sun.misc.Launcher$AppClassLoader.loadClass(Launcher.java:308)
at java.lang.ClassLoader.loadClass(ClassLoader.java:357)
... 1 more
make: *** [compile] Error 1
-
I think this error is coming because there is no
`org.apache.commons.compress.compressors.CompressorException`. I don't know
how to install it for pylucene. Please Help!
If the additional classes you need require org.apache.commons.compressor etcc
.., you need to endure that they're found on the classpath. This is a java
error.
Andi..
Thanks,
On Tue, Aug 6, 2013 at 10:57 PM, Abhishek Gupta
abhi.bansa...@gmail.comwrote:
Thanks!! Andi :)
On Tue, Aug 6, 2013
[jira] [Commented] (LUCENE-4542) Make RECURSION_CAP in HunspellStemmer configurable
[ https://issues.apache.org/jira/browse/LUCENE-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730565#comment-13730565 ] Jan Høydahl commented on LUCENE-4542: - I believe this should be closed and set fix-version to 4.4 again? Make RECURSION_CAP in HunspellStemmer configurable -- Key: LUCENE-4542 URL: https://issues.apache.org/jira/browse/LUCENE-4542 Project: Lucene - Core Issue Type: Improvement Components: modules/analysis Affects Versions: 4.0 Reporter: Piotr Assignee: Steve Rowe Fix For: 5.0, 4.5 Attachments: Lucene-4542-javadoc.patch, LUCENE-4542.patch, LUCENE-4542-with-solr.patch Currently there is private static final int RECURSION_CAP = 2; in the code of the class HunspellStemmer. It makes using hunspell with several dictionaries almost unusable, due to bad performance (f.ex. it costs 36ms to stem long sentence in latvian for recursion_cap=2 and 5 ms for recursion_cap=1). It would be nice to be able to tune this number as needed. AFAIK this number (2) was chosen arbitrary. (it's a first issue in my life, so please forgive me any mistakes done). -- 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-4311) HunspellStemFilter returns another values than Hunspell in console / command line with same dictionaries.
[ https://issues.apache.org/jira/browse/LUCENE-4311?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved LUCENE-4311. - Resolution: Duplicate Closing this as duplicate of LUCENE-4542. You can now tune this to your liking depending on what dictionary is in use. HunspellStemFilter returns another values than Hunspell in console / command line with same dictionaries. - Key: LUCENE-4311 URL: https://issues.apache.org/jira/browse/LUCENE-4311 Project: Lucene - Core Issue Type: Bug Components: core/other Affects Versions: 3.5, 4.0-ALPHA, 3.6.1 Environment: Apache Solr 3.5 - 4.0, Apache Tomcat 7.0 Reporter: Jan Rieger Attachments: cs_CZ.aff, cs_CZ.dic When I used HunspellStemFilter for stemming the czech language text, it returns me bad results. For example word praha returns praha and prahnout, what is not correct. So I try the same in my console (Hunspell command line) with exactly same dictionaries and it returns only praha and this is correct. Can somebody help me? -- 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-4542) Make RECURSION_CAP in HunspellStemmer configurable
[ https://issues.apache.org/jira/browse/LUCENE-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl resolved LUCENE-4542. - Resolution: Fixed Closing for 4.4. Please reopen if this is wrong, but the code and changes entry were committed for 4.4 so everything should be fine. Make RECURSION_CAP in HunspellStemmer configurable -- Key: LUCENE-4542 URL: https://issues.apache.org/jira/browse/LUCENE-4542 Project: Lucene - Core Issue Type: Improvement Components: modules/analysis Affects Versions: 4.0 Reporter: Piotr Assignee: Steve Rowe Fix For: 5.0, 4.4 Attachments: Lucene-4542-javadoc.patch, LUCENE-4542.patch, LUCENE-4542-with-solr.patch Currently there is private static final int RECURSION_CAP = 2; in the code of the class HunspellStemmer. It makes using hunspell with several dictionaries almost unusable, due to bad performance (f.ex. it costs 36ms to stem long sentence in latvian for recursion_cap=2 and 5 ms for recursion_cap=1). It would be nice to be able to tune this number as needed. AFAIK this number (2) was chosen arbitrary. (it's a first issue in my life, so please forgive me any mistakes done). -- 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-4542) Make RECURSION_CAP in HunspellStemmer configurable
[ https://issues.apache.org/jira/browse/LUCENE-4542?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jan Høydahl updated LUCENE-4542: Fix Version/s: (was: 4.5) 4.4 Make RECURSION_CAP in HunspellStemmer configurable -- Key: LUCENE-4542 URL: https://issues.apache.org/jira/browse/LUCENE-4542 Project: Lucene - Core Issue Type: Improvement Components: modules/analysis Affects Versions: 4.0 Reporter: Piotr Assignee: Steve Rowe Fix For: 5.0, 4.4 Attachments: Lucene-4542-javadoc.patch, LUCENE-4542.patch, LUCENE-4542-with-solr.patch Currently there is private static final int RECURSION_CAP = 2; in the code of the class HunspellStemmer. It makes using hunspell with several dictionaries almost unusable, due to bad performance (f.ex. it costs 36ms to stem long sentence in latvian for recursion_cap=2 and 5 ms for recursion_cap=1). It would be nice to be able to tune this number as needed. AFAIK this number (2) was chosen arbitrary. (it's a first issue in my life, so please forgive me any mistakes done). -- 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-5103) Plugin Improvements
[ https://issues.apache.org/jira/browse/SOLR-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730663#comment-13730663 ] Grant Ingersoll commented on SOLR-5103: --- Hoss, A few of my thoughts on it: # I don't think the config necessarily needs to be in the plugin. Part of the goal here is to be able to easily add a plugin and then easily configure it and manage it (from the UI?). # Plugins should be self-contained and (ideally) class loader isolated # You shouldn't necessarily have to restart Solr in order to add a plugin Plugin Improvements --- Key: SOLR-5103 URL: https://issues.apache.org/jira/browse/SOLR-5103 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Fix For: 5.0 I think for 5.0, we should make it easier to add plugins by defining a plugin package, ala a Hadoop Job jar, which is a self--contained archive of a plugin that can be easily installed (even from the UI!) and configured programmatically. -- 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-5107) LukeRequestHandler throws NullPointerException when numTerms=0
[
https://issues.apache.org/jira/browse/SOLR-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730665#comment-13730665
]
Erick Erickson commented on SOLR-5107:
--
Hoss:
Looks good to me.
LukeRequestHandler throws NullPointerException when numTerms=0
--
Key: SOLR-5107
URL: https://issues.apache.org/jira/browse/SOLR-5107
Project: Solr
Issue Type: Bug
Affects Versions: 4.4
Reporter: Ahmet Arslan
Assignee: Hoss Man
Priority: Minor
Attachments: SOLR-5107.patch, SOLR-5107.patch
Defaults example
http://localhost:8983/solr/collection1/admin/luke?fl=catnumTerms=0 yields
{code}
ERROR org.apache.solr.core.SolrCore – java.lang.NullPointerException
at
org.apache.solr.handler.admin.LukeRequestHandler.getDetailedFieldInfo(LukeRequestHandler.java:610)
at
org.apache.solr.handler.admin.LukeRequestHandler.getIndexedFieldsInfo(LukeRequestHandler.java:378)
at
org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:160)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1845)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:666)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:369)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:722)
{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] [Commented] (LUCENE-5156) CompressingTermVectors termsEnum should probably not support seek-by-ord
[ https://issues.apache.org/jira/browse/LUCENE-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730673#comment-13730673 ] Michael McCandless commented on LUCENE-5156: +1 CompressingTermVectors termsEnum should probably not support seek-by-ord Key: LUCENE-5156 URL: https://issues.apache.org/jira/browse/LUCENE-5156 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-5156.patch Just like term vectors before it, it has a O(n) seek-by-term. But this one also advertises a seek-by-ord, only this is also O(n). This could cause e.g. checkindex to be very slow, because if termsenum supports ord it does a bunch of seeking tests. (Another solution would be to leave it, and add a boolean so checkindex never does seeking tests for term vectors, only real fields). However, I think its also kinda a trap, in my opinion if seek-by-ord is supported anywhere, you kinda expect it to be faster than linear time...? -- 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-5156) CompressingTermVectors termsEnum should probably not support seek-by-ord
[ https://issues.apache.org/jira/browse/LUCENE-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730688#comment-13730688 ] Adrien Grand commented on LUCENE-5156: -- Patch looks good, +1 CompressingTermVectors termsEnum should probably not support seek-by-ord Key: LUCENE-5156 URL: https://issues.apache.org/jira/browse/LUCENE-5156 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-5156.patch Just like term vectors before it, it has a O(n) seek-by-term. But this one also advertises a seek-by-ord, only this is also O(n). This could cause e.g. checkindex to be very slow, because if termsenum supports ord it does a bunch of seeking tests. (Another solution would be to leave it, and add a boolean so checkindex never does seeking tests for term vectors, only real fields). However, I think its also kinda a trap, in my opinion if seek-by-ord is supported anywhere, you kinda expect it to be faster than linear time...? -- 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-5157) Refactoring MultiDocValues.OrdinalMap to clarify API and internal structure.
[ https://issues.apache.org/jira/browse/LUCENE-5157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730727#comment-13730727 ] Adrien Grand commented on LUCENE-5157: -- bq. on the other hand the fact it uses termsenum at all could be seen as an impl detail of merging (sorted)set dictionaries I tend to see it this way since ordinals are more useful on doc values than on an inverted index's terms dictionary? Refactoring MultiDocValues.OrdinalMap to clarify API and internal structure. Key: LUCENE-5157 URL: https://issues.apache.org/jira/browse/LUCENE-5157 Project: Lucene - Core Issue Type: Improvement Reporter: Boaz Leskes Priority: Minor Attachments: LUCENE-5157.patch I refactored MultiDocValues.OrdinalMap, removing one unused parameter and renaming some methods to more clearly communicate what they do. Also I renamed subIndex references to segmentIndex. -- 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-5103) Plugin Improvements
[ https://issues.apache.org/jira/browse/SOLR-5103?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730846#comment-13730846 ] Mark Miller commented on SOLR-5103: --- I think we would still need a configuration option that does not involve Java. Other than that, I don't really see too many issues. As far as names, it could possibly default to the name of the plugin jar or something else and first one wins, second one fails. We could also namespace, kind of how you see with eclipse. Honestly though, nothing sounds much better than a simple config file with the jar, same name or whatever, that has the plugin name or url. Probably that's the default minimal setup - even if you can delete that file and run with some default names or whatever for plugins that don't require any config. I think the path is obviously right - you see it used plenty elsewhere, and it resonates with me. But I think Hoss is right in that the common case will still need configuration. I don't see how the two points argue with each other though. We will need to be able to configure with a user friendly format - most plugins will have that - if not just to show the user what can be configured. There is no reason we have to require it though. Some plugin might simply be there to insert some custom code on startup. Plugin Improvements --- Key: SOLR-5103 URL: https://issues.apache.org/jira/browse/SOLR-5103 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Grant Ingersoll Fix For: 5.0 I think for 5.0, we should make it easier to add plugins by defining a plugin package, ala a Hadoop Job jar, which is a self--contained archive of a plugin that can be easily installed (even from the UI!) and configured programmatically. -- 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-5156) CompressingTermVectors termsEnum should probably not support seek-by-ord
[ https://issues.apache.org/jira/browse/LUCENE-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730869#comment-13730869 ] ASF subversion and git services commented on LUCENE-5156: - Commit 1511009 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1511009 ] LUCENE-5156: remove seek-by-ord from CompressingTermVectors CompressingTermVectors termsEnum should probably not support seek-by-ord Key: LUCENE-5156 URL: https://issues.apache.org/jira/browse/LUCENE-5156 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-5156.patch Just like term vectors before it, it has a O(n) seek-by-term. But this one also advertises a seek-by-ord, only this is also O(n). This could cause e.g. checkindex to be very slow, because if termsenum supports ord it does a bunch of seeking tests. (Another solution would be to leave it, and add a boolean so checkindex never does seeking tests for term vectors, only real fields). However, I think its also kinda a trap, in my opinion if seek-by-ord is supported anywhere, you kinda expect it to be faster than linear time...? -- 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-5156) CompressingTermVectors termsEnum should probably not support seek-by-ord
[ https://issues.apache.org/jira/browse/LUCENE-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730880#comment-13730880 ] ASF subversion and git services commented on LUCENE-5156: - Commit 1511014 from [~rcmuir] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1511014 ] LUCENE-5156: remove seek-by-ord from CompressingTermVectors CompressingTermVectors termsEnum should probably not support seek-by-ord Key: LUCENE-5156 URL: https://issues.apache.org/jira/browse/LUCENE-5156 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Attachments: LUCENE-5156.patch Just like term vectors before it, it has a O(n) seek-by-term. But this one also advertises a seek-by-ord, only this is also O(n). This could cause e.g. checkindex to be very slow, because if termsenum supports ord it does a bunch of seeking tests. (Another solution would be to leave it, and add a boolean so checkindex never does seeking tests for term vectors, only real fields). However, I think its also kinda a trap, in my opinion if seek-by-ord is supported anywhere, you kinda expect it to be faster than linear time...? -- 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-5156) CompressingTermVectors termsEnum should probably not support seek-by-ord
[ https://issues.apache.org/jira/browse/LUCENE-5156?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-5156. - Resolution: Fixed Fix Version/s: 4.5 5.0 CompressingTermVectors termsEnum should probably not support seek-by-ord Key: LUCENE-5156 URL: https://issues.apache.org/jira/browse/LUCENE-5156 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir Fix For: 5.0, 4.5 Attachments: LUCENE-5156.patch Just like term vectors before it, it has a O(n) seek-by-term. But this one also advertises a seek-by-ord, only this is also O(n). This could cause e.g. checkindex to be very slow, because if termsenum supports ord it does a bunch of seeking tests. (Another solution would be to leave it, and add a boolean so checkindex never does seeking tests for term vectors, only real fields). However, I think its also kinda a trap, in my opinion if seek-by-ord is supported anywhere, you kinda expect it to be faster than linear time...? -- 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-5119) Managed schema problems after adding fields via Schema Rest API
NilsK created SOLR-5119:
---
Summary: Managed schema problems after adding fields via Schema
Rest API
Key: SOLR-5119
URL: https://issues.apache.org/jira/browse/SOLR-5119
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.4
Reporter: NilsK
Priority: Critical
Steps to reproduce:
1. enable managed schema in example/solr/collection1/conf/solrconfig.xml
2. upload that config
{code}sh example/cloud-scripts/zkcli.sh -z localhost:8575 -cmd upconfig -d
example/solr/collection1/conf/ -n myconfig{code}
3. create a new collection
{code}curl
http://localhost:8983/solr/admin/collections?action=CREATEname=mycollectionnumShards=1replicationFactor=1collection.configName=myconfig{code}
4. add some fields
{code}curl http://localhost:8983/solr/mycollection/schema/fields -X POST -H
'Content-type:application/json' --data-binary '[
{
name: my_field,
type: string,
stored: true,
indexed: true
},
{
name: my_field2,
type: string,
stored: true,
indexed: true
}
]'{code}
5. *Problem 1*: http://localhost:8983/solr/#/mycollection_shard1_replica1/schema
{code}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status404/intint
name=QTime2/int/lstlst name=errorstr name=msgCan not find:
/configs/myconfig/null/strint name=code404/int/lst
/response
{code}
6. *Problem 2*:
http://localhost:8983/solr/admin/collections?action=RELOADname=mycollection
{code}
response
lst name=responseHeaderint name=status0/intint
name=QTime845/int/lstlst name=failurestr
name=10.147.252.2:8983_solrorg.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Server
at http://10.147.252.2:8983/solr returned non ok status:500, message:Server
Error/str/lst
/response
{code}
7. when restarting Solr, both 5 and 6 work
--
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-5119) Managed schema problems after adding fields via Schema Rest API
[
https://issues.apache.org/jira/browse/SOLR-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
NilsK updated SOLR-5119:
Description:
After adding fields with the Schema API the schema cannot be shown on the Admin
UI anymore and reloading the Collection/Core throws an NullPointerException.
The schema itself seems to work.
Steps to reproduce:
1. enable managed schema in example/solr/collection1/conf/solrconfig.xml
2. upload that config
{code}sh example/cloud-scripts/zkcli.sh -z localhost:8575 -cmd upconfig -d
example/solr/collection1/conf/ -n myconfig{code}
3. create a new collection
{code}curl
http://localhost:8983/solr/admin/collections?action=CREATEname=mycollectionnumShards=1replicationFactor=1collection.configName=myconfig{code}
4. add some fields
{code}curl http://localhost:8983/solr/mycollection/schema/fields -X POST -H
'Content-type:application/json' --data-binary '[
{
name: my_field,
type: string,
stored: true,
indexed: true
},
{
name: my_field2,
type: string,
stored: true,
indexed: true
}
]'{code}
5. *Problem 1*: http://localhost:8983/solr/#/mycollection_shard1_replica1/schema
{code}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status404/intint
name=QTime2/int/lstlst name=errorstr name=msgCan not find:
/configs/myconfig/null/strint name=code404/int/lst
/response
{code}
6. *Problem 2*:
http://localhost:8983/solr/admin/collections?action=RELOADname=mycollection
{code}
response
lst name=responseHeaderint name=status0/intint
name=QTime845/int/lstlst name=failurestr
name=10.147.252.2:8983_solrorg.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Server
at http://10.147.252.2:8983/solr returned non ok status:500, message:Server
Error/str/lst
/response
{code}
7. when restarting Solr, both 5 and 6 work
was:
Steps to reproduce:
1. enable managed schema in example/solr/collection1/conf/solrconfig.xml
2. upload that config
{code}sh example/cloud-scripts/zkcli.sh -z localhost:8575 -cmd upconfig -d
example/solr/collection1/conf/ -n myconfig{code}
3. create a new collection
{code}curl
http://localhost:8983/solr/admin/collections?action=CREATEname=mycollectionnumShards=1replicationFactor=1collection.configName=myconfig{code}
4. add some fields
{code}curl http://localhost:8983/solr/mycollection/schema/fields -X POST -H
'Content-type:application/json' --data-binary '[
{
name: my_field,
type: string,
stored: true,
indexed: true
},
{
name: my_field2,
type: string,
stored: true,
indexed: true
}
]'{code}
5. *Problem 1*: http://localhost:8983/solr/#/mycollection_shard1_replica1/schema
{code}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status404/intint
name=QTime2/int/lstlst name=errorstr name=msgCan not find:
/configs/myconfig/null/strint name=code404/int/lst
/response
{code}
6. *Problem 2*:
http://localhost:8983/solr/admin/collections?action=RELOADname=mycollection
{code}
response
lst name=responseHeaderint name=status0/intint
name=QTime845/int/lstlst name=failurestr
name=10.147.252.2:8983_solrorg.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Server
at http://10.147.252.2:8983/solr returned non ok status:500, message:Server
Error/str/lst
/response
{code}
7. when restarting Solr, both 5 and 6 work
Managed schema problems after adding fields via Schema Rest API
Key: SOLR-5119
URL: https://issues.apache.org/jira/browse/SOLR-5119
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.4
Reporter: NilsK
Priority: Critical
After adding fields with the Schema API the schema cannot be shown on the
Admin UI anymore and reloading the Collection/Core throws an
NullPointerException. The schema itself seems to work.
Steps to reproduce:
1. enable managed schema in example/solr/collection1/conf/solrconfig.xml
2. upload that config
{code}sh example/cloud-scripts/zkcli.sh -z localhost:8575 -cmd upconfig -d
example/solr/collection1/conf/ -n myconfig{code}
3. create a new collection
{code}curl
http://localhost:8983/solr/admin/collections?action=CREATEname=mycollectionnumShards=1replicationFactor=1collection.configName=myconfig{code}
4. add some fields
{code}curl http://localhost:8983/solr/mycollection/schema/fields -X POST -H
'Content-type:application/json' --data-binary '[
{
name: my_field,
type: string,
stored: true,
indexed: true
},
{
name: my_field2,
type: string,
stored: true,
indexed: true
}
]'{code}
5. *Problem 1*:
http://localhost:8983/solr/#/mycollection_shard1_replica1/schema
{code}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status404/intint
name=QTime2/int/lstlst name=errorstr name=msgCan not find:
[jira] [Commented] (SOLR-4952) audit test configs to use solrconfig.snippet.randomindexconfig.xml in more tests
[
https://issues.apache.org/jira/browse/SOLR-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730983#comment-13730983
]
ASF subversion and git services commented on SOLR-4952:
---
Commit 1511044 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1511044 ]
SOLR-4952: ConvertedLegacyTest shouldn't assuming an absolute score now that we
are randomizing merge policy settings, term stats may fluctuate
audit test configs to use solrconfig.snippet.randomindexconfig.xml in more
tests
Key: SOLR-4952
URL: https://issues.apache.org/jira/browse/SOLR-4952
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
in SOLR-4942 i updated every solrconfig.xml to either...
* include solrconfig.snippet.randomindexconfig.xml where it was easy to do so
* use the useCompoundFile sys prop if it already had an {{indexConfig}}
section, or if including the snippet wasn't going to be easy (ie: contrib
tests)
As an improvment on this:
* audit all core configs not already using
solrconfig.snippet.randomindexconfig.xml and either:
** make them use it, ignoring any previously unimportant explicit
incdexConfig settings
** make them use it, using explicit sys props to overwrite random values in
cases were explicit indexConfig values are important for test
** add a comment why it's not using the include snippet in cases where the
explicit parsing is part of hte test
* try figure out a way for contrib tests to easily include the same file
and/or apply the same rules as above
--
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: Problem using TrecTopicsReader()
Thanks!! Andi :) On Tue, Aug 6, 2013 at 5:17 PM, Andi Vajda va...@apache.org wrote: On Aug 6, 2013, at 10:36, Abhishek Gupta abhi.bansa...@gmail.com wrote: Hi, I have a problem using TrecTopicsReader which I have already asked on #lucene IRC but got no reply till yesterday. I also post it on SO( http://stackoverflow.com/questions/18054649/bufferedreader-in-pylucne). The problem is completely explained on SO. In the PyLucene Makefile find the jcc invocation and add java.io.BufferedReader to the long command line (don't forget the ending \ as needed) and rebuild PyLucene. Andi.. Please Help!! Thanking You Abhishek Gupta, 9416106204, 9624799165 -- Abhishek Gupta, 897876422, 9416106204, 9624799165
[jira] [Commented] (SOLR-5081) Highly parallel document insertion hangs SolrCloud
[ https://issues.apache.org/jira/browse/SOLR-5081?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730995#comment-13730995 ] Yago Riveiro commented on SOLR-5081: I have this problem too, but in my case, Solr hangs and I can done more insertions without restart the nodes. I do the insertion using a culr post in json format like: curl http://127.0.0.1:8983/solr/collection/update --data-binary @data -H 'Content-type:application/json' Highly parallel document insertion hangs SolrCloud -- Key: SOLR-5081 URL: https://issues.apache.org/jira/browse/SOLR-5081 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.3.1 Reporter: Mike Schrag Attachments: threads.txt If I do a highly parallel document load using a Hadoop cluster into an 18 node solrcloud cluster, I can deadlock solr every time. The ulimits on the nodes are: core file size (blocks, -c) 0 data seg size (kbytes, -d) unlimited scheduling priority (-e) 0 file size (blocks, -f) unlimited pending signals (-i) 1031181 max locked memory (kbytes, -l) unlimited max memory size (kbytes, -m) unlimited open files (-n) 32768 pipe size(512 bytes, -p) 8 POSIX message queues (bytes, -q) 819200 real-time priority (-r) 0 stack size (kbytes, -s) 10240 cpu time (seconds, -t) unlimited max user processes (-u) 515590 virtual memory (kbytes, -v) unlimited file locks (-x) unlimited The open file count is only around 4000 when this happens. If I bounce all the servers, things start working again, which makes me think this is Solr and not ZK. I'll attach the stack trace from one of the servers. -- 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-4952) audit test configs to use solrconfig.snippet.randomindexconfig.xml in more tests
[
https://issues.apache.org/jira/browse/SOLR-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13730993#comment-13730993
]
ASF subversion and git services commented on SOLR-4952:
---
Commit 1511046 from hoss...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1511046 ]
SOLR-4952: ConvertedLegacyTest shouldn't assuming an absolute score now that we
are randomizing merge policy settings, term stats may fluctuate (merge r1511044)
audit test configs to use solrconfig.snippet.randomindexconfig.xml in more
tests
Key: SOLR-4952
URL: https://issues.apache.org/jira/browse/SOLR-4952
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
in SOLR-4942 i updated every solrconfig.xml to either...
* include solrconfig.snippet.randomindexconfig.xml where it was easy to do so
* use the useCompoundFile sys prop if it already had an {{indexConfig}}
section, or if including the snippet wasn't going to be easy (ie: contrib
tests)
As an improvment on this:
* audit all core configs not already using
solrconfig.snippet.randomindexconfig.xml and either:
** make them use it, ignoring any previously unimportant explicit
incdexConfig settings
** make them use it, using explicit sys props to overwrite random values in
cases were explicit indexConfig values are important for test
** add a comment why it's not using the include snippet in cases where the
explicit parsing is part of hte test
* try figure out a way for contrib tests to easily include the same file
and/or apply the same rules as above
--
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-5107) LukeRequestHandler throws NullPointerException when numTerms=0
[
https://issues.apache.org/jira/browse/SOLR-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731054#comment-13731054
]
ASF subversion and git services commented on SOLR-5107:
---
Commit 1511064 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1511064 ]
SOLR-5107: Fixed NPE when using numTerms=0 in LukeRequestHandler
LukeRequestHandler throws NullPointerException when numTerms=0
--
Key: SOLR-5107
URL: https://issues.apache.org/jira/browse/SOLR-5107
Project: Solr
Issue Type: Bug
Affects Versions: 4.4
Reporter: Ahmet Arslan
Assignee: Hoss Man
Priority: Minor
Attachments: SOLR-5107.patch, SOLR-5107.patch
Defaults example
http://localhost:8983/solr/collection1/admin/luke?fl=catnumTerms=0 yields
{code}
ERROR org.apache.solr.core.SolrCore – java.lang.NullPointerException
at
org.apache.solr.handler.admin.LukeRequestHandler.getDetailedFieldInfo(LukeRequestHandler.java:610)
at
org.apache.solr.handler.admin.LukeRequestHandler.getIndexedFieldsInfo(LukeRequestHandler.java:378)
at
org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:160)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1845)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:666)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:369)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:722)
{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] [Commented] (SOLR-5107) LukeRequestHandler throws NullPointerException when numTerms=0
[
https://issues.apache.org/jira/browse/SOLR-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731083#comment-13731083
]
ASF subversion and git services commented on SOLR-5107:
---
Commit 1511069 from hoss...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1511069 ]
SOLR-5107: Fixed NPE when using numTerms=0 in LukeRequestHandler (merge
r1511064)
LukeRequestHandler throws NullPointerException when numTerms=0
--
Key: SOLR-5107
URL: https://issues.apache.org/jira/browse/SOLR-5107
Project: Solr
Issue Type: Bug
Affects Versions: 4.4
Reporter: Ahmet Arslan
Assignee: Hoss Man
Priority: Minor
Attachments: SOLR-5107.patch, SOLR-5107.patch
Defaults example
http://localhost:8983/solr/collection1/admin/luke?fl=catnumTerms=0 yields
{code}
ERROR org.apache.solr.core.SolrCore – java.lang.NullPointerException
at
org.apache.solr.handler.admin.LukeRequestHandler.getDetailedFieldInfo(LukeRequestHandler.java:610)
at
org.apache.solr.handler.admin.LukeRequestHandler.getIndexedFieldsInfo(LukeRequestHandler.java:378)
at
org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:160)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1845)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:666)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:369)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:722)
{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] [Resolved] (SOLR-5107) LukeRequestHandler throws NullPointerException when numTerms=0
[
https://issues.apache.org/jira/browse/SOLR-5107?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-5107.
Resolution: Fixed
Fix Version/s: 5.0
4.5
thanks Ahmet and Erick
LukeRequestHandler throws NullPointerException when numTerms=0
--
Key: SOLR-5107
URL: https://issues.apache.org/jira/browse/SOLR-5107
Project: Solr
Issue Type: Bug
Affects Versions: 4.4
Reporter: Ahmet Arslan
Assignee: Hoss Man
Priority: Minor
Fix For: 4.5, 5.0
Attachments: SOLR-5107.patch, SOLR-5107.patch
Defaults example
http://localhost:8983/solr/collection1/admin/luke?fl=catnumTerms=0 yields
{code}
ERROR org.apache.solr.core.SolrCore – java.lang.NullPointerException
at
org.apache.solr.handler.admin.LukeRequestHandler.getDetailedFieldInfo(LukeRequestHandler.java:610)
at
org.apache.solr.handler.admin.LukeRequestHandler.getIndexedFieldsInfo(LukeRequestHandler.java:378)
at
org.apache.solr.handler.admin.LukeRequestHandler.handleRequestBody(LukeRequestHandler.java:160)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1845)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:666)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:369)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:722)
{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] (SOLR-5113) CollectionsAPIDistributedZkTest fails all the time
[ https://issues.apache.org/jira/browse/SOLR-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-5113: - Attachment: SOLR-5113.patch all tests pass . can somebody just confirm CollectionsAPIDistributedZkTest fails all the time -- Key: SOLR-5113 URL: https://issues.apache.org/jira/browse/SOLR-5113 Project: Solr Issue Type: Bug Components: Tests Affects Versions: 4.5, 5.0 Reporter: Uwe Schindler Assignee: Noble Paul Priority: Blocker Attachments: SOLR-5113.patch -- 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-5120) Solrj Query response error with result number
Łukasz Woźniczka created SOLR-5120:
--
Summary: Solrj Query response error with result number
Key: SOLR-5120
URL: https://issues.apache.org/jira/browse/SOLR-5120
Project: Solr
Issue Type: Bug
Environment: linux, lubuntu, java version 1.7.0_13.
Reporter: Łukasz Woźniczka
Priority: Critical
This is my simple code :
QueryResponse qr;
try {
qr = fs.execute(solrServer);
System.out.println(QUERY RESPONSE : + qr);
for (EntryString, Object r : qr.getResponse()) {
System.out.println(RESPONSE: + r.getKey() + - +
r.getValue());
}
SolrDocumentList dl = qr.getResults();
System.out.println(--RESULT SIZE:[ + dl.size() );
} catch (SolrServerException e) {
e.printStackTrace();
}
I am using solrj and solr-core version 4.4.0. And there is a bug probably in
solrj in query result. I am creating one simple txt doc with content 'anna' and
then i am restar solr and try to search this phrase. Nothing is found but this
is my query response system out {numFound=1,start=1,docs=[]}.
So as you can see ther is info that numFound=1 but docs=[] -- is empty. Next i
add another document with only one word 'anna' and then try search that string
and this is sysout;
{numFound=2,start=1,docs=[SolrDocument{file_id=9882, file_name=luk-search2.txt,
file_create_user=-1, file_department=10, file_mime_type=text/plain,
file_extension=.txt, file_parents_folder=[5021, 4781, 341, -20, -1],
_version_=1442647024934584320}]}
So as you can see ther is numFound = 2 but only one document is listed.
--
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] [Closed] (SOLR-5120) Solrj Query response error with result number
[
https://issues.apache.org/jira/browse/SOLR-5120?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shawn Heisey closed SOLR-5120.
--
Resolution: Not A Problem
This should have been brought up on the solr-user mailing list, or perhaps the
IRC channel. Even if it were actually a bug, which it's not, it should have
been discussed first.
http://lucene.apache.org/solr/discussion.html
Your response indicates that your query has a start parameter of 1. If that
had been set to zero or omitted entirely, you would have seen both results.
Solrj Query response error with result number
--
Key: SOLR-5120
URL: https://issues.apache.org/jira/browse/SOLR-5120
Project: Solr
Issue Type: Bug
Environment: linux, lubuntu, java version 1.7.0_13.
Reporter: Łukasz Woźniczka
Priority: Critical
This is my simple code :
QueryResponse qr;
try {
qr = fs.execute(solrServer);
System.out.println(QUERY RESPONSE : + qr);
for (EntryString, Object r : qr.getResponse()) {
System.out.println(RESPONSE: + r.getKey() + - +
r.getValue());
}
SolrDocumentList dl = qr.getResults();
System.out.println(--RESULT SIZE:[ + dl.size() );
} catch (SolrServerException e) {
e.printStackTrace();
}
I am using solrj and solr-core version 4.4.0. And there is a bug probably in
solrj in query result. I am creating one simple txt doc with content 'anna'
and then i am restar solr and try to search this phrase. Nothing is found but
this is my query response system out {numFound=1,start=1,docs=[]}.
So as you can see ther is info that numFound=1 but docs=[] -- is empty. Next
i add another document with only one word 'anna' and then try search that
string and this is sysout;
{numFound=2,start=1,docs=[SolrDocument{file_id=9882,
file_name=luk-search2.txt, file_create_user=-1, file_department=10,
file_mime_type=text/plain, file_extension=.txt, file_parents_folder=[5021,
4781, 341, -20, -1], _version_=1442647024934584320}]}
So as you can see ther is numFound = 2 but only one document is listed.
--
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
Interesting failure scenario, SolrCloud and ZK nodes on different times
I've become aware of a situation I thought I'd pass along. A SolrCloud installation had several ZK nodes that has very significantly offset times. They were being hit with the ClusterState says we are the leader, but locally we don't think we are error when nodes were recovering. Of course whether this problem is now taken care of with recent Solr releases (I haven't seen this go by the user's list for quite a while) I don't quite know. When the times were coordinated, many of the problems with recovery went away. We're trying to reconstruct the scenario from memory, but it prompted me to pass the incident in case it sparked any thoughts. Specifically, I wonder if there's anything that comes to mind if the ZK nodes are significantly out of synch with each other time-wise. FWIW, Erick
[jira] [Commented] (SOLR-5113) CollectionsAPIDistributedZkTest fails all the time
[
https://issues.apache.org/jira/browse/SOLR-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731195#comment-13731195
]
Hoss Man commented on SOLR-5113:
Noble:
1) i notice in your patch that you've modified an assertion, and then commented
it out -- is that a mistake, should that assertion be enabled?
2) 3 failures out of 10 iterations of the test with your patch applied and run
using -Dtests.dups=10 ... but 3 is also the magic number of JVMs i use to run
parallel tests, and all 3 failures looked like this...
{noformat}
[junit4] 2 NOTE: reproduce with: ant test
-Dtestcase=CollectionsAPIDistributedZkTest -Dtests.method=testDistribSearch
-Dtests.seed=5E287730E2C75B9B -Dtests.slow=true -Dtests.locale=ar_QA
-Dtests.timezone=America/Noronha -Dtests.file.encoding=UTF-8
[junit4] ERROR116s J1 |
CollectionsAPIDistributedZkTest.testDistribSearch
[junit4] Throwable #1:
org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
collection already exists: implicitcoll0
[junit4]at
__randomizedtesting.SeedInfo.seed([5E287730E2C75B9B:DFCEF92895983BA7]:0)
[junit4]at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:424)
[junit4]at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
[junit4]at
org.apache.solr.client.solrj.impl.LBHttpSolrServer.request(LBHttpSolrServer.java:264)
[junit4]at
org.apache.solr.client.solrj.impl.CloudSolrServer.request(CloudSolrServer.java:318)
[junit4]at
org.apache.solr.cloud.AbstractFullDistribZkTestBase.createCollection(AbstractFullDistribZkTestBase.java:1537)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.testCustomCollectionsAPI(CollectionsAPIDistributedZkTest.java:678)
[junit4]at
org.apache.solr.cloud.CollectionsAPIDistributedZkTest.doTest(CollectionsAPIDistributedZkTest.java:155)
[junit4]at
org.apache.solr.BaseDistributedSearchTestCase.testDistribSearch(BaseDistributedSearchTestCase.java:835)
[junit4]at java.lang.Thread.run(Thread.java:724)
{noformat}
...when i tried with -Dtests.jvms=4 i got 4 failures out of 10
CollectionsAPIDistributedZkTest fails all the time
--
Key: SOLR-5113
URL: https://issues.apache.org/jira/browse/SOLR-5113
Project: Solr
Issue Type: Bug
Components: Tests
Affects Versions: 4.5, 5.0
Reporter: Uwe Schindler
Assignee: Noble Paul
Priority: Blocker
Attachments: SOLR-5113.patch
--
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-4952) audit test configs to use solrconfig.snippet.randomindexconfig.xml in more tests
[
https://issues.apache.org/jira/browse/SOLR-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731298#comment-13731298
]
ASF subversion and git services commented on SOLR-4952:
---
Commit 1511123 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1511123 ]
SOLR-4952: missed the repeater config used in TestReplicationHandler
audit test configs to use solrconfig.snippet.randomindexconfig.xml in more
tests
Key: SOLR-4952
URL: https://issues.apache.org/jira/browse/SOLR-4952
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
in SOLR-4942 i updated every solrconfig.xml to either...
* include solrconfig.snippet.randomindexconfig.xml where it was easy to do so
* use the useCompoundFile sys prop if it already had an {{indexConfig}}
section, or if including the snippet wasn't going to be easy (ie: contrib
tests)
As an improvment on this:
* audit all core configs not already using
solrconfig.snippet.randomindexconfig.xml and either:
** make them use it, ignoring any previously unimportant explicit
incdexConfig settings
** make them use it, using explicit sys props to overwrite random values in
cases were explicit indexConfig values are important for test
** add a comment why it's not using the include snippet in cases where the
explicit parsing is part of hte test
* try figure out a way for contrib tests to easily include the same file
and/or apply the same rules as above
--
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-4952) audit test configs to use solrconfig.snippet.randomindexconfig.xml in more tests
[
https://issues.apache.org/jira/browse/SOLR-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731302#comment-13731302
]
ASF subversion and git services commented on SOLR-4952:
---
Commit 1511126 from hoss...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1511126 ]
SOLR-4952: missed the repeater config used in TestReplicationHandler (merge
r1511123)
audit test configs to use solrconfig.snippet.randomindexconfig.xml in more
tests
Key: SOLR-4952
URL: https://issues.apache.org/jira/browse/SOLR-4952
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
in SOLR-4942 i updated every solrconfig.xml to either...
* include solrconfig.snippet.randomindexconfig.xml where it was easy to do so
* use the useCompoundFile sys prop if it already had an {{indexConfig}}
section, or if including the snippet wasn't going to be easy (ie: contrib
tests)
As an improvment on this:
* audit all core configs not already using
solrconfig.snippet.randomindexconfig.xml and either:
** make them use it, ignoring any previously unimportant explicit
incdexConfig settings
** make them use it, using explicit sys props to overwrite random values in
cases were explicit indexConfig values are important for test
** add a comment why it's not using the include snippet in cases where the
explicit parsing is part of hte test
* try figure out a way for contrib tests to easily include the same file
and/or apply the same rules as above
--
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: Interesting failure scenario, SolrCloud and ZK nodes on different times
On 8/6/2013 1:56 PM, Erick Erickson wrote: I've become aware of a situation I thought I'd pass along. A SolrCloud installation had several ZK nodes that has very significantly offset times. They were being hit with the ClusterState says we are the leader, but locally we don't think we are error when nodes were recovering. Of course whether this problem is now taken care of with recent Solr releases (I haven't seen this go by the user's list for quite a while) I don't quite know. When the times were coordinated, many of the problems with recovery went away. We're trying to reconstruct the scenario from memory, but it prompted me to pass the incident in case it sparked any thoughts. Specifically, I wonder if there's anything that comes to mind if the ZK nodes are significantly out of synch with each other time-wise. Does this mean that ntp or other strict time synchronization is important for SolrCloud? I strive for this anyway, just to ensure that when I'm researching log files between two machines that I can match things up properly. Thanks, Shawn - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4952) audit test configs to use solrconfig.snippet.randomindexconfig.xml in more tests
[
https://issues.apache.org/jira/browse/SOLR-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731336#comment-13731336
]
ASF subversion and git services commented on SOLR-4952:
---
Commit 1511128 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1511128 ]
SOLR-4952: TestSolrDeletionPolicy1 can't directly use
solrconfig.snippet.randomindexconfig.xml - but it can leverage the random sys
props directly
audit test configs to use solrconfig.snippet.randomindexconfig.xml in more
tests
Key: SOLR-4952
URL: https://issues.apache.org/jira/browse/SOLR-4952
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
in SOLR-4942 i updated every solrconfig.xml to either...
* include solrconfig.snippet.randomindexconfig.xml where it was easy to do so
* use the useCompoundFile sys prop if it already had an {{indexConfig}}
section, or if including the snippet wasn't going to be easy (ie: contrib
tests)
As an improvment on this:
* audit all core configs not already using
solrconfig.snippet.randomindexconfig.xml and either:
** make them use it, ignoring any previously unimportant explicit
incdexConfig settings
** make them use it, using explicit sys props to overwrite random values in
cases were explicit indexConfig values are important for test
** add a comment why it's not using the include snippet in cases where the
explicit parsing is part of hte test
* try figure out a way for contrib tests to easily include the same file
and/or apply the same rules as above
--
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: Interesting failure scenario, SolrCloud and ZK nodes on different times
: When the times were coordinated, many of the problems with recovery went : away. We're trying to reconstruct the scenario from memory, but it : prompted me to pass the incident in case it sparked any thoughts. : Specifically, I wonder if there's anything that comes to mind if the ZK : nodes are significantly out of synch with each other time-wise. : : Does this mean that ntp or other strict time synchronization is important for : SolrCloud? I strive for this anyway, just to ensure that when I'm researching : log files between two machines that I can match things up properly. I don't know if/how Solr/ZK is affected by having machines with clocks out of sync, but i do remember seeing discussions a while back about weird things happening ot ZK client apps *while* time adjustments are taking place to get back in sync. IIRC: as the local clock starts accelerating and jumping ahead in increments to correct itself with ntp, then those jumps can confuse the ZK code into thinking it's been waiting a lot longer then it really has for zk heartbeat (or whatever it's called) and it can trigger a timeout situation. -Hoss - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4952) audit test configs to use solrconfig.snippet.randomindexconfig.xml in more tests
[
https://issues.apache.org/jira/browse/SOLR-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731348#comment-13731348
]
ASF subversion and git services commented on SOLR-4952:
---
Commit 1511129 from hoss...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1511129 ]
SOLR-4952: TestSolrDeletionPolicy1 can't directly use
solrconfig.snippet.randomindexconfig.xml - but it can leverage the random sys
props directly (merge r1511128)
audit test configs to use solrconfig.snippet.randomindexconfig.xml in more
tests
Key: SOLR-4952
URL: https://issues.apache.org/jira/browse/SOLR-4952
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
in SOLR-4942 i updated every solrconfig.xml to either...
* include solrconfig.snippet.randomindexconfig.xml where it was easy to do so
* use the useCompoundFile sys prop if it already had an {{indexConfig}}
section, or if including the snippet wasn't going to be easy (ie: contrib
tests)
As an improvment on this:
* audit all core configs not already using
solrconfig.snippet.randomindexconfig.xml and either:
** make them use it, ignoring any previously unimportant explicit
incdexConfig settings
** make them use it, using explicit sys props to overwrite random values in
cases were explicit indexConfig values are important for test
** add a comment why it's not using the include snippet in cases where the
explicit parsing is part of hte test
* try figure out a way for contrib tests to easily include the same file
and/or apply the same rules as above
--
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-4952) audit test configs to use solrconfig.snippet.randomindexconfig.xml in more tests
[
https://issues.apache.org/jira/browse/SOLR-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731366#comment-13731366
]
ASF subversion and git services commented on SOLR-4952:
---
Commit 1511134 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1511134 ]
SOLR-4952: get SolrCoreCheckLockOnStartupTest using
solrconfig.snippet.randomindexconfig.xml
audit test configs to use solrconfig.snippet.randomindexconfig.xml in more
tests
Key: SOLR-4952
URL: https://issues.apache.org/jira/browse/SOLR-4952
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
in SOLR-4942 i updated every solrconfig.xml to either...
* include solrconfig.snippet.randomindexconfig.xml where it was easy to do so
* use the useCompoundFile sys prop if it already had an {{indexConfig}}
section, or if including the snippet wasn't going to be easy (ie: contrib
tests)
As an improvment on this:
* audit all core configs not already using
solrconfig.snippet.randomindexconfig.xml and either:
** make them use it, ignoring any previously unimportant explicit
incdexConfig settings
** make them use it, using explicit sys props to overwrite random values in
cases were explicit indexConfig values are important for test
** add a comment why it's not using the include snippet in cases where the
explicit parsing is part of hte test
* try figure out a way for contrib tests to easily include the same file
and/or apply the same rules as above
--
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-4952) audit test configs to use solrconfig.snippet.randomindexconfig.xml in more tests
[
https://issues.apache.org/jira/browse/SOLR-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731374#comment-13731374
]
ASF subversion and git services commented on SOLR-4952:
---
Commit 1511137 from hoss...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1511137 ]
SOLR-4952: get SolrCoreCheckLockOnStartupTest using
solrconfig.snippet.randomindexconfig.xml (merge r1511134)
audit test configs to use solrconfig.snippet.randomindexconfig.xml in more
tests
Key: SOLR-4952
URL: https://issues.apache.org/jira/browse/SOLR-4952
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
in SOLR-4942 i updated every solrconfig.xml to either...
* include solrconfig.snippet.randomindexconfig.xml where it was easy to do so
* use the useCompoundFile sys prop if it already had an {{indexConfig}}
section, or if including the snippet wasn't going to be easy (ie: contrib
tests)
As an improvment on this:
* audit all core configs not already using
solrconfig.snippet.randomindexconfig.xml and either:
** make them use it, ignoring any previously unimportant explicit
incdexConfig settings
** make them use it, using explicit sys props to overwrite random values in
cases were explicit indexConfig values are important for test
** add a comment why it's not using the include snippet in cases where the
explicit parsing is part of hte test
* try figure out a way for contrib tests to easily include the same file
and/or apply the same rules as above
--
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-4764) When using NRT, just init the reader from IndexWriter
[ https://issues.apache.org/jira/browse/SOLR-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-4764: -- Attachment: SOLR-4764_test.patch here's a test. When using NRT, just init the reader from IndexWriter - Key: SOLR-4764 URL: https://issues.apache.org/jira/browse/SOLR-4764 Project: Solr Issue Type: Improvement Reporter: Robert Muir Attachments: SOLR-4764_test.patch Spinoff from SOLR-4761 Solr first opens a DirectoryReader from the directory, then later will pass this to IW openIfChanged. I noticed this when i was confused that mergedsegmentwarmer doesn't appear to work at first until after you've reopened... I'm not totally sure what the current behavior causes (does IW's pool reuse segments from this passed-in external reader, or is this causing some horrible doubling-up/inefficient stuff etc?). To some extent i think we should change it even if its actually performant: I think its confusing. I think ideally we'd change IndexReaderFactory's method to take writer instead of directory so that custom DirectoryReaders can still work. -- 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-4952) audit test configs to use solrconfig.snippet.randomindexconfig.xml in more tests
[
https://issues.apache.org/jira/browse/SOLR-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731386#comment-13731386
]
ASF subversion and git services commented on SOLR-4952:
---
Commit 1511138 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1511138 ]
SOLR-4952: TestSolrDeletionPolicy2 can't directly use
solrconfig.snippet.randomindexconfig.xml - but it can leverage the random sys
props directly
audit test configs to use solrconfig.snippet.randomindexconfig.xml in more
tests
Key: SOLR-4952
URL: https://issues.apache.org/jira/browse/SOLR-4952
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
in SOLR-4942 i updated every solrconfig.xml to either...
* include solrconfig.snippet.randomindexconfig.xml where it was easy to do so
* use the useCompoundFile sys prop if it already had an {{indexConfig}}
section, or if including the snippet wasn't going to be easy (ie: contrib
tests)
As an improvment on this:
* audit all core configs not already using
solrconfig.snippet.randomindexconfig.xml and either:
** make them use it, ignoring any previously unimportant explicit
incdexConfig settings
** make them use it, using explicit sys props to overwrite random values in
cases were explicit indexConfig values are important for test
** add a comment why it's not using the include snippet in cases where the
explicit parsing is part of hte test
* try figure out a way for contrib tests to easily include the same file
and/or apply the same rules as above
--
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-4952) audit test configs to use solrconfig.snippet.randomindexconfig.xml in more tests
[
https://issues.apache.org/jira/browse/SOLR-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731388#comment-13731388
]
ASF subversion and git services commented on SOLR-4952:
---
Commit 1511139 from hoss...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1511139 ]
SOLR-4952: TestSolrDeletionPolicy2 can't directly use
solrconfig.snippet.randomindexconfig.xml - but it can leverage the random sys
props directly
audit test configs to use solrconfig.snippet.randomindexconfig.xml in more
tests
Key: SOLR-4952
URL: https://issues.apache.org/jira/browse/SOLR-4952
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
in SOLR-4942 i updated every solrconfig.xml to either...
* include solrconfig.snippet.randomindexconfig.xml where it was easy to do so
* use the useCompoundFile sys prop if it already had an {{indexConfig}}
section, or if including the snippet wasn't going to be easy (ie: contrib
tests)
As an improvment on this:
* audit all core configs not already using
solrconfig.snippet.randomindexconfig.xml and either:
** make them use it, ignoring any previously unimportant explicit
incdexConfig settings
** make them use it, using explicit sys props to overwrite random values in
cases were explicit indexConfig values are important for test
** add a comment why it's not using the include snippet in cases where the
explicit parsing is part of hte test
* try figure out a way for contrib tests to easily include the same file
and/or apply the same rules as above
--
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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731408#comment-13731408 ] Andrew Muldowney commented on SOLR-2894: I've found a small error which causes largely sharded (30+) data to spiral out of control on refinement requests. I've fixed the error on a previous version of solr and I'll be forward porting it to my 4_4 build by tomorrow. If you are having issues with complex string fields this should help. Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.5 Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894-reworked.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-2894) Implement distributed pivot faceting
[ https://issues.apache.org/jira/browse/SOLR-2894?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731433#comment-13731433 ] Otis Gospodnetic commented on SOLR-2894: [~andrew.muldowney] - I didn't have time to link issues, but [~joel.bernstein] is working on at least one issue that is, if I recall correctly, an alternative implementation of this Implement distributed pivot faceting Key: SOLR-2894 URL: https://issues.apache.org/jira/browse/SOLR-2894 Project: Solr Issue Type: Improvement Reporter: Erik Hatcher Fix For: 4.5 Attachments: SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894.patch, SOLR-2894-reworked.patch Following up on SOLR-792, pivot faceting currently only supports undistributed mode. Distributed pivot faceting needs to be implemented. -- 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-5114) stop tracking IndexCommit in replication handler
[ https://issues.apache.org/jira/browse/SOLR-5114?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-5114: --- Attachment: SOLR-5114.patch Mostly working snapshot patch. Trying to figure out what the current behavior is supposed to be in many different scenarios is difficult. One test fails: testEmptyCommits... stop tracking IndexCommit in replication handler Key: SOLR-5114 URL: https://issues.apache.org/jira/browse/SOLR-5114 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Priority: Trivial Attachments: SOLR-5114.patch It seems like indexCommitPoint tries to track the latest index commit. This doesn't seem necessary and could lead to bugs if it's not tracked correctly. We should always be able to ask the deletion policy for the latest commit (including a fallback mechanism if no IW has yet been opened) -- 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-5114) stop tracking IndexCommit in replication handler
[ https://issues.apache.org/jira/browse/SOLR-5114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731453#comment-13731453 ] Yonik Seeley edited comment on SOLR-5114 at 8/6/13 11:51 PM: - Mostly working snapshot patch. Trying to figure out what the current behavior is supposed to be in many different scenarios is difficult. One test fails: testEmptyCommits... edit: oh, this patch also removes a race condition between getting an index commit and reserving it. was (Author: ysee...@gmail.com): Mostly working snapshot patch. Trying to figure out what the current behavior is supposed to be in many different scenarios is difficult. One test fails: testEmptyCommits... stop tracking IndexCommit in replication handler Key: SOLR-5114 URL: https://issues.apache.org/jira/browse/SOLR-5114 Project: Solr Issue Type: Improvement Reporter: Yonik Seeley Priority: Trivial Attachments: SOLR-5114.patch It seems like indexCommitPoint tries to track the latest index commit. This doesn't seem necessary and could lead to bugs if it's not tracked correctly. We should always be able to ask the deletion policy for the latest commit (including a fallback mechanism if no IW has yet been opened) -- 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-4764) When using NRT, just init the reader from IndexWriter
[ https://issues.apache.org/jira/browse/SOLR-4764?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-4764: -- Attachment: SOLR-4764.patch Here is a patch. All tests pass. A few notes: * the init respects the existing 'reopenReaders' in solrconfig.xml, so if you have that set to false, it still does the same thing as before. * IndexReaderFactory gets a newReader(IndexWriter, ..) so that NRT users can still customize the DirectoryReader being used. * A few tests relied upon the fact that init didnt open an indexwriter: MultiCoreExampleTestBase always created a core container and opened cores, so this was moved to the embedded subclass which needs it. The ReplicationHandler test and the TestArbitraryIndexDir just set reopenReaders=false because they rely fundamentally on this 'readonly' case. When using NRT, just init the reader from IndexWriter - Key: SOLR-4764 URL: https://issues.apache.org/jira/browse/SOLR-4764 Project: Solr Issue Type: Improvement Reporter: Robert Muir Attachments: SOLR-4764.patch, SOLR-4764_test.patch Spinoff from SOLR-4761 Solr first opens a DirectoryReader from the directory, then later will pass this to IW openIfChanged. I noticed this when i was confused that mergedsegmentwarmer doesn't appear to work at first until after you've reopened... I'm not totally sure what the current behavior causes (does IW's pool reuse segments from this passed-in external reader, or is this causing some horrible doubling-up/inefficient stuff etc?). To some extent i think we should change it even if its actually performant: I think its confusing. I think ideally we'd change IndexReaderFactory's method to take writer instead of directory so that custom DirectoryReaders can still work. -- 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
OutOfMemoryError in TermContext.build
Hi folks
I am running a mapreduce which generates More Like This for a list of
documents. For every source document, a set of important words is picked by
generating a TermQuery for a word and seeing the score of the query using
searcher.explain()
My index size on disk is 362MB and I have started solr with 4GB of memory.
However, i'm getting this exception which i'm not able to understand:
Caused by: java.lang.OutOfMemoryError: GC overhead limit exceeded
at
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum$Frame.init(BlockTreeTermsReader.java:2266)
at
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum.getFrame(BlockTreeTermsReader.java:1414)
at
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum.pushFrame(BlockTreeTermsReader.java:1445)
at
org.apache.lucene.codecs.BlockTreeTermsReader$FieldReader$SegmentTermsEnum.seekExact(BlockTreeTermsReader.java:1658)
at org.apache.lucene.index.TermContext.build(TermContext.java:95)
at
org.apache.lucene.search.TermQuery.createWeight(TermQuery.java:166)
at
org.apache.lucene.search.ConstantScoreQuery$ConstantWeight.init(ConstantScoreQuery.java:101)
at
org.apache.lucene.search.ConstantScoreQuery.createWeight(ConstantScoreQuery.java:270)
at
com.bloomreach.rp.ScoreSquashingQuery.createWeight(ScoreSquashingQuery.java:46)
at
org.apache.lucene.search.BooleanQuery$BooleanWeight.init(BooleanQuery.java:183)
at
org.apache.lucene.search.BooleanQuery.createWeight(BooleanQuery.java:384)
at
com.bloomreach.rp.ScoreSquashingQuery.createWeight(ScoreSquashingQuery.java:46)
at
org.apache.lucene.search.IndexSearcher.createNormalizedWeight(IndexSearcher.java:675)
at
org.apache.lucene.search.IndexSearcher.explain(IndexSearcher.java:643)
at
org.apache.solr.search.SolrIndexSearcher.explain(SolrIndexSearcher.java:2058)
at
com.bloomreach.rp.MLTQueryParser.computeScoreForWordOrPhrase(MLTQueryParser.java:321)
I tried digging into the code for TermQuery.createWeight(), the function
says that its caching the term lookup:
public Weight createWeight(IndexSearcher searcher) throws IOException {
...
// make TermQuery single-pass if we don't have a PRTS or if the
context differs!
termState = TermContext.build(context, term, true); // cache term
lookups!
But how can this cause an OOM, i thought the index is already a map from
term to doc,field,position that is loaded in memory, why is this loading
anything extra in memory?
Thanks
Gagan
[jira] [Commented] (SOLR-5113) CollectionsAPIDistributedZkTest fails all the time
[
https://issues.apache.org/jira/browse/SOLR-5113?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13731579#comment-13731579
]
Noble Paul commented on SOLR-5113:
--
Thanks Hoss
bq.should that assertion be enabled?
That assertion should be enabled. But I'm baffled when I see
{noformat}
[junit4] ERROR 53.3s | CollectionsAPIDistributedZkTest.testDistribSearch
[junit4] Throwable #1:
org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException: Server at
http://127.0.0.1:55245/iv/y/implicitcoll0 returned non ok status:503,
message:Service Unavailable
{noformat}
Considering that the previous statement inserted one doc into the same url.
However I wanted to ensure that others are able to confirm if this much is
passing
I see the tests failing when the test is the last one to run , and passing when
I moved to the top.
I'm wondering , how do the no:of JVMs affect the testitself
CollectionsAPIDistributedZkTest fails all the time
--
Key: SOLR-5113
URL: https://issues.apache.org/jira/browse/SOLR-5113
Project: Solr
Issue Type: Bug
Components: Tests
Affects Versions: 4.5, 5.0
Reporter: Uwe Schindler
Assignee: Noble Paul
Priority: Blocker
Attachments: SOLR-5113.patch
--
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-Windows (32bit/jdk1.8.0-ea-b99) - Build # 3121 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Windows/3121/ Java: 32bit/jdk1.8.0-ea-b99 -server -XX:+UseG1GC 1 tests failed. REGRESSION: org.apache.lucene.index.TestIndexWriterOutOfFileDescriptors.test Error Message: unreferenced files: before delete: [_0_TestBloomFilteredLucene41Postings_0.doc, _0_TestBloomFilteredLucene41Postings_0.pos, _k.fdt, _k.fdx, _k.fnm, _k.nvd, _k.nvm, _k.si, _k.tvd, _k.tvx, _k_Lucene41WithOrds_0.doc, _k_Lucene41WithOrds_0.pos, _k_Lucene41WithOrds_0.tib, _k_Lucene41WithOrds_0.tii, _k_Lucene42_0.dvd, _k_Lucene42_0.dvm, _k_MockFixedIntBlock_0.doc, _k_MockFixedIntBlock_0.frq, _k_MockFixedIntBlock_0.pos, _k_MockFixedIntBlock_0.pyl, _k_MockFixedIntBlock_0.skp, _k_MockFixedIntBlock_0.tib, _k_MockFixedIntBlock_0.tii, _k_MockVariableIntBlock_0.doc, _k_MockVariableIntBlock_0.frq, _k_MockVariableIntBlock_0.pos, _k_MockVariableIntBlock_0.pyl, _k_MockVariableIntBlock_0.skp, _k_MockVariableIntBlock_0.tib, _k_MockVariableIntBlock_0.tii, _k_TestBloomFilteredLucene41Postings_0.blm, _k_TestBloomFilteredLucene41Postings_0.doc, _k_TestBloomFilteredLucene41Postings_0.pos, _k_TestBloomFilteredLucene41Postings_0.tim, _k_TestBloomFilteredLucene41Postings_0.tip, _l.fdt, _l.fdx, _l.fnm, _l.nvd, _l.nvm, _l.si, _l.tvd, _l.tvx, _l_Lucene41WithOrds_0.doc, _l_Lucene41WithOrds_0.pos, _l_Lucene41WithOrds_0.tib, _l_Lucene41WithOrds_0.tii, _l_Lucene42_0.dvd, _l_Lucene42_0.dvm, _l_MockFixedIntBlock_0.doc, _l_MockFixedIntBlock_0.frq, _l_MockFixedIntBlock_0.pos, _l_MockFixedIntBlock_0.pyl, _l_MockFixedIntBlock_0.skp, _l_MockFixedIntBlock_0.tib, _l_MockFixedIntBlock_0.tii, _l_MockVariableIntBlock_0.doc, _l_MockVariableIntBlock_0.frq, _l_MockVariableIntBlock_0.pos, _l_MockVariableIntBlock_0.pyl, _l_MockVariableIntBlock_0.skp, _l_MockVariableIntBlock_0.tib, _l_MockVariableIntBlock_0.tii, _l_TestBloomFilteredLucene41Postings_0.blm, _l_TestBloomFilteredLucene41Postings_0.doc, _l_TestBloomFilteredLucene41Postings_0.pos, _l_TestBloomFilteredLucene41Postings_0.tim, _l_TestBloomFilteredLucene41Postings_0.tip, _m.cfe, _m.cfs, _m.si, _n.cfe, _n.cfs, _n.si, _o.fdt, _o.fdx, _o.fnm, _o.nvd, _o.nvm, _o.si, _o.tvd, _o.tvx, _o_Lucene41WithOrds_0.doc, _o_Lucene41WithOrds_0.pos, _o_Lucene41WithOrds_0.tib, _o_Lucene41WithOrds_0.tii, _o_Lucene42_0.dvd, _o_Lucene42_0.dvm, _o_MockFixedIntBlock_0.doc, _o_MockFixedIntBlock_0.frq, _o_MockFixedIntBlock_0.pos, _o_MockFixedIntBlock_0.pyl, _o_MockFixedIntBlock_0.skp, _o_MockFixedIntBlock_0.tib, _o_MockFixedIntBlock_0.tii, _o_MockVariableIntBlock_0.doc, _o_MockVariableIntBlock_0.frq, _o_MockVariableIntBlock_0.pos, _o_MockVariableIntBlock_0.pyl, _o_MockVariableIntBlock_0.skp, _o_MockVariableIntBlock_0.tib, _o_MockVariableIntBlock_0.tii, _o_TestBloomFilteredLucene41Postings_0.blm, _o_TestBloomFilteredLucene41Postings_0.doc, _o_TestBloomFilteredLucene41Postings_0.pos, _o_TestBloomFilteredLucene41Postings_0.tim, _o_TestBloomFilteredLucene41Postings_0.tip, _q.fdt, _q.fdx, _q.fnm, _q.nvd, _q.nvm, _q.si, _q.tvd, _q.tvx, _q_Lucene41WithOrds_0.doc, _q_Lucene41WithOrds_0.pos, _q_Lucene41WithOrds_0.tib, _q_Lucene41WithOrds_0.tii, _q_Lucene42_0.dvd, _q_Lucene42_0.dvm, _q_MockFixedIntBlock_0.doc, _q_MockFixedIntBlock_0.frq, _q_MockFixedIntBlock_0.pos, _q_MockFixedIntBlock_0.pyl, _q_MockFixedIntBlock_0.skp, _q_MockFixedIntBlock_0.tib, _q_MockFixedIntBlock_0.tii, _q_MockVariableIntBlock_0.doc, _q_MockVariableIntBlock_0.frq, _q_MockVariableIntBlock_0.pos, _q_MockVariableIntBlock_0.pyl, _q_MockVariableIntBlock_0.skp, _q_MockVariableIntBlock_0.tib, _q_MockVariableIntBlock_0.tii, _q_TestBloomFilteredLucene41Postings_0.blm, _q_TestBloomFilteredLucene41Postings_0.doc, _q_TestBloomFilteredLucene41Postings_0.pos, _q_TestBloomFilteredLucene41Postings_0.tim, _q_TestBloomFilteredLucene41Postings_0.tip, _r.fdt, _r.fdx, _r.fnm, _r.nvd, _r.nvm, _r.si, _r.tvd, _r.tvx, _r_Lucene41WithOrds_0.doc, _r_Lucene41WithOrds_0.pay, _r_Lucene41WithOrds_0.pos, _r_Lucene41WithOrds_0.tib, _r_Lucene41WithOrds_0.tii, _r_Lucene42_0.dvd, _r_Lucene42_0.dvm, _r_MockFixedIntBlock_0.doc, _r_MockFixedIntBlock_0.frq, _r_MockFixedIntBlock_0.pos, _r_MockFixedIntBlock_0.pyl, _r_MockFixedIntBlock_0.skp, _r_MockFixedIntBlock_0.tib, _r_MockFixedIntBlock_0.tii, _r_MockVariableIntBlock_0.doc, _r_MockVariableIntBlock_0.frq, _r_MockVariableIntBlock_0.pos, _r_MockVariableIntBlock_0.pyl, _r_MockVariableIntBlock_0.skp, _r_MockVariableIntBlock_0.tib, _r_MockVariableIntBlock_0.tii, _r_TestBloomFilteredLucene41Postings_0.blm, _r_TestBloomFilteredLucene41Postings_0.doc, _r_TestBloomFilteredLucene41Postings_0.pay, _r_TestBloomFilteredLucene41Postings_0.pos, _r_TestBloomFilteredLucene41Postings_0.tim, _r_TestBloomFilteredLucene41Postings_0.tip, _s.fdt, _s.fdx, _s.fnm, _s.nvd, _s.nvm, _s.si, _s.tvd, _s.tvx, _s_Lucene41WithOrds_0.doc, _s_Lucene41WithOrds_0.pos, _s_Lucene41WithOrds_0.tib, _s_Lucene41WithOrds_0.tii, _s_Lucene42_0.dvd, _s_Lucene42_0.dvm,
