Re: DLL load failed: The specified module could not be found. from jcc import _jcc
Hi Thomas, Thanks for the follow up. I have resolved this by instead using SOLR, which provides a REST interface and scalability for my web application. There also are hosted solutions which offer SOLR which make deploying the solution easier. It did require me to go back and refactor my code :-( but at least is working well. Thanks. On Fri, Aug 24, 2012 at 12:29 AM, Thomas Koch k...@orbiteam.de wrote: Hi Carlos, Just another hint: did you try do load jcc.dll within the MOD_WSGI script? I recently wrote down some hints on typical pitfalls in the apache-extra pylucene wiki at http://code.google.com/a/apache-extras.org/p/pylucene-extra/wiki/PyLucene try to call import ctypes ctypes.windll.LoadLibrary(jcc.dll) in your script. If that doesn't help to find the origin of your problem I'd start to look at mod_wsgi debugging opportunities to see where/why it fails. Regards, Thomas -Ursprüngliche Nachricht- Von: Carlos Ferreira [mailto:to.carlos.ferre...@gmail.com] Gesendet: Samstag, 18. August 2012 02:09 An: pylucene-dev@lucene.apache.org Betreff: Re: DLL load failed: The specified module could not be found. from jcc import _jcc Hi Thomas, Thank you for your response. I don't believe it is a system path or missing dll problem. As the example I provided shows it works when I invoke it from the Python Shell within the command line that includes the statement import jcc. MOD_WSGI also works and shows my current path when I invoke a test WSGI script. The test MOD_WSGI script fails however when I include the import jcc statement. This seems like it is a easy to reproduce problem. Your thought about not allowing it to be called within another process might be right but need more info and it may not help since I am on Windows XP which I understand doesn't support WSGIDaemonProcess would allow a separate process to run. Is there anyone else at pylucene that might be able to help? Or maybe point me to the patch that was proposed to see if that fixes the problem? Thanks for your help. Carlos On Thu, Aug 16, 2012 at 12:05 AM, Thomas Koch k...@orbiteam.de wrote: Dear Carlos, haven't used mod_wsgi so far, but remember there was a patch submitted to the list related to mod_wsgi : Von: Patrick J. McNerthney [mailto:pmcnerth...@ncircle.com] Gesendet: Freitag, 6. Juli 2012 05:40 An: pylucene-dev@lucene.apache.org Betreff: Supporting mod_wsgi python sub-interpreters I would like to propose the attached patch to support the use of python sub- interpreters, which are used by mod_wsgi. If there is interest, I can further clarify. Pat That hasn't been discussed further, but maybe Pat can comment on what the patch was good for or what problem it solves? BTW, the error you encounter may not be related to the python interpreter not finding jcc.dll but rather that jcc.dll cannot be loaded in the current process - e.g. because of wrong path in environment. I can for example reproduce this by setting PATH=C:\ and invoke python: Python 2.7.2 (default, Jun 12 2011, 15:08:59) [MSC v.1500 32 bit (Intel)] on win32 Type help, copyright, credits or license for more information. import jcc Traceback (most recent call last): File stdin, line 1, in module File c:\Devel\Python27\lib\site-packages\jcc-2.13-py2.7-win32.egg\jcc\__in it__.p y, line 31, in module from jcc import _jcc ImportError: DLL load failed: Das angegebene Modul wurde nicht gefunden. A typical problem in not being able to import lucene/jcc is a missing DLL (msvcr71.DLL) which is required by the loaded DLL. Sometimes it helps to load the DLL directly - in a command shell (interpreter) environment for example a windows dialogue may popup and tell you about the missing DLL. That may not work in a server process... Hope that helps. Regards, Thomas -Ursprüngliche Nachricht- Von: Carlos Ferreira [mailto:to.carlos.ferre...@gmail.com] Gesendet: Donnerstag, 16. August 2012 04:17 An: pylucene-dev@lucene.apache.org Betreff: DLL load failed: The specified module could not be found. from jcc import _jcc Hi, Please help I am unable to get Pylucene working with JCC on Apache 2.22 using Mod_WSGI on Windows XP. *Works from Command Line* C:\python Python 2.7.1 (r271:86832, Nov 27 2010 18:30:46) [MSC v.1500 32 bit (Intel)] on win32 import jcc from jcc import _jcc dir (_jcc) [‘Boolean’, ‘Bye’, ‘CLASSPATH’, ….. Works from Command Line C:\python c:\Python27\Lib\site-packages\JCC-2.13-py2.7-win32.egg\jcc\__init__. py JCC – C++/Python Java Native Interface Code Generator Usage: python –m jcc.__main__ [options] [actions]
[jira] [Updated] (PYLUCENE-23) OSError
[
https://issues.apache.org/jira/browse/PYLUCENE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
goog cheng updated PYLUCENE-23:
---
Description:
after type sudo python setup.py build , and terminal outputs:
/usr/lib/python2.7/distutils/extension.py:133: UserWarning: Unknown Extension
options: 'force_shared'
warnings.warn(msg)
Traceback (most recent call last):
File setup.py, line 382, in module
main('--debug' in sys.argv)
File setup.py, line 327, in main
raise type(e), %s: %s %(e, args)
OSError: [Errno 2] No such file or directory: ['javac', '-d', 'jcc/classes',
'java/org/apache/jcc/PythonVM.java', 'java/org/apache/jcc/PythonException.java']
googcheng@googcheng-TravelMate-4530:~/Downloads/pylucene-3.6.1-2/jcc$ sudo
python setup.py build
/usr/lib/python2.7/distutils/extension.py:133: UserWarning: Unknown Extension
options: 'force_shared'
warnings.warn(msg)
Traceback (most recent call last):
File setup.py, line 382, in module
main('--debug' in sys.argv)
File setup.py, line 327, in main
raise type(e), %s: %s %(e, args)
OSError: [Errno 2] No such file or directory: ['javac', '-d', 'jcc/classes',
'java/org/apache/jcc/PythonVM.java', 'java/org/apache/jcc/PythonException.java']
was:
sudo python setup.py build
/usr/lib/python2.7/distutils/extension.py:133: UserWarning: Unknown Extension
options: 'force_shared'
warnings.warn(msg)
Traceback (most recent call last):
File setup.py, line 382, in module
main('--debug' in sys.argv)
File setup.py, line 327, in main
raise type(e), %s: %s %(e, args)
OSError: [Errno 2] No such file or directory: ['javac', '-d', 'jcc/classes',
'java/org/apache/jcc/PythonVM.java', 'java/org/apache/jcc/PythonException.java']
googcheng@googcheng-TravelMate-4530:~/Downloads/pylucene-3.6.1-2/jcc$ sudo
python setup.py build
/usr/lib/python2.7/distutils/extension.py:133: UserWarning: Unknown Extension
options: 'force_shared'
warnings.warn(msg)
Traceback (most recent call last):
File setup.py, line 382, in module
main('--debug' in sys.argv)
File setup.py, line 327, in main
raise type(e), %s: %s %(e, args)
OSError: [Errno 2] No such file or directory: ['javac', '-d', 'jcc/classes',
'java/org/apache/jcc/PythonVM.java', 'java/org/apache/jcc/PythonException.java']
OSError
---
Key: PYLUCENE-23
URL: https://issues.apache.org/jira/browse/PYLUCENE-23
Project: PyLucene
Issue Type: Bug
Environment: ubuntu12.04 python2.7
Reporter: goog cheng
after type sudo python setup.py build , and terminal outputs:
/usr/lib/python2.7/distutils/extension.py:133: UserWarning: Unknown Extension
options: 'force_shared'
warnings.warn(msg)
Traceback (most recent call last):
File setup.py, line 382, in module
main('--debug' in sys.argv)
File setup.py, line 327, in main
raise type(e), %s: %s %(e, args)
OSError: [Errno 2] No such file or directory: ['javac', '-d', 'jcc/classes',
'java/org/apache/jcc/PythonVM.java',
'java/org/apache/jcc/PythonException.java']
googcheng@googcheng-TravelMate-4530:~/Downloads/pylucene-3.6.1-2/jcc$ sudo
python setup.py build
/usr/lib/python2.7/distutils/extension.py:133: UserWarning: Unknown Extension
options: 'force_shared'
warnings.warn(msg)
Traceback (most recent call last):
File setup.py, line 382, in module
main('--debug' in sys.argv)
File setup.py, line 327, in main
raise type(e), %s: %s %(e, args)
OSError: [Errno 2] No such file or directory: ['javac', '-d', 'jcc/classes',
'java/org/apache/jcc/PythonVM.java',
'java/org/apache/jcc/PythonException.java']
--
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
[jira] [Updated] (PYLUCENE-23) OSError
[
https://issues.apache.org/jira/browse/PYLUCENE-23?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
goog cheng updated PYLUCENE-23:
---
Description:
after type sudo python setup.py build , and terminal outputs:
googcheng@googcheng-TravelMate-4530:~/Downloads/pylucene-3.6.1-2/jcc$ sudo
python setup.py build
/usr/lib/python2.7/distutils/extension.py:133: UserWarning: Unknown Extension
options: 'force_shared'
warnings.warn(msg)
Traceback (most recent call last):
File setup.py, line 382, in module
main('--debug' in sys.argv)
File setup.py, line 327, in main
raise type(e), %s: %s %(e, args)
OSError: [Errno 2] No such file or directory: ['javac', '-d', 'jcc/classes',
'java/org/apache/jcc/PythonVM.java', 'java/org/apache/jcc/PythonException.java']
was:
after type sudo python setup.py build , and terminal outputs:
/usr/lib/python2.7/distutils/extension.py:133: UserWarning: Unknown Extension
options: 'force_shared'
warnings.warn(msg)
Traceback (most recent call last):
File setup.py, line 382, in module
main('--debug' in sys.argv)
File setup.py, line 327, in main
raise type(e), %s: %s %(e, args)
OSError: [Errno 2] No such file or directory: ['javac', '-d', 'jcc/classes',
'java/org/apache/jcc/PythonVM.java', 'java/org/apache/jcc/PythonException.java']
googcheng@googcheng-TravelMate-4530:~/Downloads/pylucene-3.6.1-2/jcc$ sudo
python setup.py build
/usr/lib/python2.7/distutils/extension.py:133: UserWarning: Unknown Extension
options: 'force_shared'
warnings.warn(msg)
Traceback (most recent call last):
File setup.py, line 382, in module
main('--debug' in sys.argv)
File setup.py, line 327, in main
raise type(e), %s: %s %(e, args)
OSError: [Errno 2] No such file or directory: ['javac', '-d', 'jcc/classes',
'java/org/apache/jcc/PythonVM.java', 'java/org/apache/jcc/PythonException.java']
OSError
---
Key: PYLUCENE-23
URL: https://issues.apache.org/jira/browse/PYLUCENE-23
Project: PyLucene
Issue Type: Bug
Environment: ubuntu12.04 python2.7
Reporter: goog cheng
after type sudo python setup.py build , and terminal outputs:
googcheng@googcheng-TravelMate-4530:~/Downloads/pylucene-3.6.1-2/jcc$ sudo
python setup.py build
/usr/lib/python2.7/distutils/extension.py:133: UserWarning: Unknown Extension
options: 'force_shared'
warnings.warn(msg)
Traceback (most recent call last):
File setup.py, line 382, in module
main('--debug' in sys.argv)
File setup.py, line 327, in main
raise type(e), %s: %s %(e, args)
OSError: [Errno 2] No such file or directory: ['javac', '-d', 'jcc/classes',
'java/org/apache/jcc/PythonVM.java',
'java/org/apache/jcc/PythonException.java']
--
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
Re: Build failed in Jenkins: Lucene-Core-4x-Beasting #8125
Yup, something is odd. The quit event is the last one emitted from a forked jvm and it should always be received. It'd be great if you could capture the workspace (or just the temporary build files -- **/*.events); I'm sure it's possible to keep these as part of each build -- they're removed on successful completion anyway so it'll affect failed builds only. Could you configure this somehow? Dawid On Thu, Sep 20, 2012 at 2:09 AM, Robert Muir rcm...@gmail.com wrote: this looks like a bug in the testrunner? all tests are actually done executing here. On Wed, Sep 19, 2012 at 8:02 PM, hudsonsevilt...@gmail.com wrote: See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8125/ -- [...truncated 8788 lines...] compile-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: init: compile-lucene-core: compile-codecs: [echo] Building codecs... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: compile-core: compile-core: common.compile-test: install-junit4-taskdef: -clover.disable: -clover.setup: clover: validate: common.test: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/build/memory/test [junit4:junit4] JUnit4 says olá! Master seed: 71BB57BBEF1760E0 [junit4:junit4] Executing 1 suite with 1 JVM. [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.memory.MemoryIndexTest [junit4:junit4] Completed in 3.32s, 5 tests [junit4:junit4] [junit4:junit4] JVM J0: 0.31 .. 4.14 = 3.83s [junit4:junit4] Execution time total: 4.14 sec. [junit4:junit4] Tests summary: 1 suite, 5 tests [echo] 5 slowest tests: [junit4:tophints] 3.32s | org.apache.lucene.index.memory.MemoryIndexTest [echo] Building misc... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: init: -clover.disable: -clover.setup: clover: compile-core: init: test: [echo] Building misc... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: compile-test: [echo] Building misc... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: compile-core: compile-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: init: compile-lucene-core: compile-codecs: [echo] Building codecs... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: compile-core: compile-core: common.compile-test: install-junit4-taskdef: -clover.disable: -clover.setup: clover: validate: common.test: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/build/misc/test [junit4:junit4] JUnit4 says Привет! Master seed: 618B11506A5D [junit4:junit4] Executing 5 suites with 4 JVMs. [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.misc.SweetSpotSimilarityTest [junit4:junit4] Completed on J3 in 0.44s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestMultiPassIndexSplitter [junit4:junit4] Completed on J3 in 1.32s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.misc.TestHighFreqTerms [junit4:junit4] Completed on J2 in 1.69s, 11 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestPKIndexSplitter [junit4:junit4] Completed on J1 in 1.70s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestIndexSplitter [junit4:junit4] Completed on J0 in 8.24s, 1 test
[jira] [Commented] (SOLR-3857) DIH: SqlEntityProcessor with simple cache broken
[
https://issues.apache.org/jira/browse/SOLR-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459392#comment-13459392
]
Mikhail Khludnev commented on SOLR-3857:
James,
Could you explain what can be actually cached in N+1 scenario (where
xid=${x.id}) ?
DIH: SqlEntityProcessor with simple cache broken
--
Key: SOLR-3857
URL: https://issues.apache.org/jira/browse/SOLR-3857
Project: Solr
Issue Type: Bug
Affects Versions: 3.6.1, 4.0-BETA
Reporter: James Dyer
The wiki describes a usage of CachedSqlEntityProcessor like this:
{code:xml}
entity name=y query=select * from y where xid=${x.id}
processor=CachedSqlEntityProcessor
{code}
This creates what the code refers as a simple cache. Rather than build the
entire cache up-front, the cache is built on-the-go. I think this has
limited use cases but it would be nice to preserve the feature if possible.
Unfortunately this was not included in any (effective) unit tests, and
SOLR-2382 entirely broke the functionality for 3.6/4.0-alpha+ . At a first
glance, the fix may not be entirely straightforward.
This was found while writing tests for SOLR-3856.
--
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-3851) create a new core/delete an existing core should also update the main/left list of cores
[ https://issues.apache.org/jira/browse/SOLR-3851?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3851: Attachment: SOLR-3851.patch first draft create a new core/delete an existing core should also update the main/left list of cores Key: SOLR-3851 URL: https://issues.apache.org/jira/browse/SOLR-3851 Project: Solr Issue Type: Improvement Components: web gui Affects Versions: 4.0-BETA Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.0 Attachments: SOLR-3851.patch While working on SOLR-3788, i realized that the main/left list of cores needs/should also be updated when a new core is created / an existing core is deleted, which is right now not the fact. On a first quick look that should not be that hard, hopefully we can reuse existing functionality from app.js, which already generates a list of cores when the UI is initialized. -- 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-3783) Facet pivots produces NPE when facet.missing is turned on
[
https://issues.apache.org/jira/browse/SOLR-3783?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459435#comment-13459435
]
Tanguy Moal commented on SOLR-3783:
---
Thank you very much!
I just patched my copy of Solr 4.0 Beta with it and redeployed my snapshot.
Works like a charm.
Facet pivots produces NPE when facet.missing is turned on
-
Key: SOLR-3783
URL: https://issues.apache.org/jira/browse/SOLR-3783
Project: Solr
Issue Type: Bug
Components: SearchComponents - other
Reporter: Tanguy Moal
Assignee: Hoss Man
Priority: Minor
Fix For: 4.0, 5.0
Attachments: SOLR-3783.patch
We get an http 500 as follow :
{code:xml}
lst name=error
str name=tracejava.lang.NullPointerException/str
int name=code500/int
/lst
{code}
When facet.missing is turned on and combined with facet.pivot (if one of the
pivot-faceted fields have missing counts ^-^)
Ideally, the decission tree could be computing for the missing entries
using the {noformat} -field:[* TO *] {noformat} query but it might be a
performance issue on a large index (I guess)
The fallback to this could be to raise a 400 error with a clean message
telling that both parameters can't be combined and then the documentation
should be modified accordingly.
--
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: jar error while trying to build
Thank you so much Andi. This is what ended up working for me, on Red Hat Enterprise Linux Server release 6.1: PREFIX_PYTHON=/usr ANT=/opt/ant/bin/ant JAVA_HOME=/usr/java/jdk1.6.0_29 PYTHON=$(PREFIX_PYTHON)/bin/python JCC=$(PYTHON) -m jcc.__main__ NUM_FILES=200 On Wed, Sep 19, 2012 at 3:46 PM, Andi Vajda va...@apache.org wrote: On Sep 19, 2012, at 12:43, Mohamed Lrhazi ml...@georgetown.edu wrote: Oh, I was missing this var: PREFIX_PYTHON=/usr Now I am moving a bit further and failing at: /usr/bin/python: jcc is a package and cannot be directly executed make: *** [compile] Error 1 Your python invocation of jcc is wrong. Depending on the version, you must use the right syntax. There are plenty of examples in the Makefile for many python versions. Andi.. what else did I miss :) Thanks a lot, Mohamed. On Wed, Sep 19, 2012 at 3:32 PM, Andi Vajda va...@apache.org wrote: On Sep 19, 2012, at 12:29, Mohamed Lrhazi ml...@georgetown.edu wrote: On Wed, Sep 19, 2012 at 2:28 PM, Andi Vajda va...@apache.org wrote: What does 'make print-GENERATE' return ? I'll try to dig more into the Makefile world... been a long time. ml623@cab2b:~/tmp/pylucene-3.6.1-2/ make print-GENERATE which: no icupkg in (/opt/ActivePython-2.6/bin:/usr/sbin:/sbin:/opt/ruby-enterprise/bin:/usr/local/bin:/bin:/usr/bin:/usr/local/sbin:/usr/sbin:/sbin:/home/ml623//bin:/usr/X11R6/bin:/usr/loca/bin) GENERATE = /bin/python -m jcc --shared --jar lucene-java-3.6.1/lucene/build/core/lucene-core-3.6.1.jar --jar lucene-java-3.6.1/lucene/build/contrib/analyzers/common/lucene-analyzers-3.6.1.jar --jar lucene-java-3.6.1/lucene/build/contrib/memory/lucene-memory-3.6.1.jar --jar lucene-java-3.6.1/lucene/build/contrib/highlighter/lucene-highlighter-3.6.1.jar --jar build/jar/extensions.jar --jar lucene-java-3.6.1/lucene/build/contrib/queries/lucene-queries-3.6.1.jar --jar lucene-java-3.6.1/lucene/build/contrib/grouping/lucene-grouping-3.6.1.jar --jar lucene-java-3.6.1/lucene/build/contrib/join/lucene-join-3.6.1.jar --jar lucene-java-3.6.1/lucene/build/contrib/facet/lucene-facet-3.6.1.jar --jar lucene-java-3.6.1/lucene/build/contrib/spellchecker/lucene-spellchecker-3.6.1.jar --package java.lang java.lang.System java.lang.Runtime java.lang.IllegalStateException java.lang.IndexOutOfBoundsException --package java.util java.util.Arrays java.util.HashMap java.util.HashSet java.util.NoSuchElementException java.text.SimpleDateFormat java.text.DecimalFormat java.text.Collator --package java.util.regex --package java.io java.io.StringReader java.io.InputStreamReader java.io.FileInputStream --exclude org.apache.lucene.queryParser.Token --exclude org.apache.lucene.queryParser.TokenMgrError --exclude org.apache.lucene.queryParser.QueryParserTokenManager --exclude org.apache.lucene.queryParser.ParseException --exclude org.apache.lucene.queryParser.CharStream --exclude org.apache.lucene.search.regex.JakartaRegexpCapabilities --exclude org.apache.regexp.RegexpTunnel --exclude org.apache.lucene.analysis.cn.smart.AnalyzerProfile --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; --rename org.apache.lucene.search.highlight.SpanScorer=HighlighterSpanScorer --rename org.apache.lucene.search.highlight.Scorer=HighlighterScorer --rename org.apache.lucene.search.spell.Dictionary=SpellDictionary --rename org.apache.lucene.search.suggest.fst.Sort=SuggestSort --rename org.apache.lucene.store.DataInput=StoreDataInput --rename org.apache.lucene.store.DataOutput=StoreDataOutput --rename org.tartarus.snowball.ext.DutchStemmer=DutchPorterStemmer --rename org.tartarus.snowball.ext.FrenchStemmer=FrenchPorterStemmer --rename org.tartarus.snowball.ext.GermanStemmer=GermanPorterStemmer --rename org.tartarus.snowball.ext.PortugueseStemmer=PortuguesePorterStemmer --version 3.6.1 --module python/collections.py --module python/ICUNormalizer2Filter.py --module python/ICUFoldingFilter.py --module python/ICUTransformFilter.py --files 4 This looks correct to me. What happens when paste this complete command into your shell ? Andi..
Build failed in Jenkins: Lucene-Solr-Robocop #109
See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/109/ -- Started by timer Started by timer Started by timer Started by timer Started by timer Started by timer Started by timer Started by timer Started by timer Building in workspace http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/ Cleaning up http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/. Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/build Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/test-framework/lib/ant-1.8.2.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/test-framework/lib/junit-4.10.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/test-framework/lib/junit4-ant-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/test-framework/lib/randomizedtesting-runner-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/spatial/lib/spatial4j-0.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/sandbox/lib/jakarta-regexp-1.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/tools/lib/asm-debug-all-4.0.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/phonetic/lib/commons-codec-1.7.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/uima/lib/Tagger-2.3.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/uima/lib/WhitespaceTokenizer-2.3.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/uima/lib/uimaj-core-2.3.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/icu/lib/icu4j-49.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/morfologik/lib/morfologik-fsa-1.5.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/morfologik/lib/morfologik-polish-1.5.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/morfologik/lib/morfologik-stemming-1.5.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/demo/lib/servlet-api-2.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/benchmark/lib/commons-compress-1.4.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/benchmark/lib/nekohtml-1.9.15.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/benchmark/lib/xercesImpl-2.9.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/build Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/test-framework/lib/ant-1.8.2.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/test-framework/lib/junit-4.10.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/test-framework/lib/junit4-ant-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/test-framework/lib/randomizedtesting-runner-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/commons-io-2.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/httpclient-4.1.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/httpcore-4.1.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/httpmime-4.1.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/jcl-over-slf4j-1.6.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/log4j-over-slf4j-1.6.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/slf4j-api-1.6.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/slf4j-jdk14-1.6.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/wstx-asl-3.2.7.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/zookeeper-3.3.6.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/example/start.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/example/example-DIH/solr/db/lib/hsqldb-1.8.0.10.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/example/lib/jetty-continuation-8.1.2.v20120308.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/example/lib/jetty-deploy-8.1.2.v20120308.jar Deleting
Build failed in Jenkins: Lucene-Core-4x-Beasting #8186
See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8186/ -- Started by timer Started by timer Started by timer Started by timer Started by timer Building in workspace http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ Cleaning up http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/. Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./build Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./test-framework/lib/ant-1.8.2.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./test-framework/lib/junit-4.10.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./test-framework/lib/junit4-ant-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./test-framework/lib/randomizedtesting-runner-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./spatial/lib/spatial4j-0.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./sandbox/lib/jakarta-regexp-1.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./tools/lib/asm-debug-all-4.0.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./analysis/phonetic/lib/commons-codec-1.7.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./analysis/uima/lib/Tagger-2.3.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./analysis/uima/lib/WhitespaceTokenizer-2.3.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./analysis/uima/lib/uimaj-core-2.3.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./analysis/icu/lib/icu4j-49.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./analysis/morfologik/lib/morfologik-fsa-1.5.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./analysis/morfologik/lib/morfologik-polish-1.5.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./analysis/morfologik/lib/morfologik-stemming-1.5.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./demo/lib/servlet-api-2.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./benchmark/lib/commons-compress-1.4.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./benchmark/lib/nekohtml-1.9.15.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/./benchmark/lib/xercesImpl-2.9.1.jar Updating https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/lucene ERROR: Failed to update https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/lucene org.tmatesoft.svn.core.SVNException: svn: OPTIONS /repos/asf/lucene/dev/branches/branch_4x/lucene failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:291) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:276) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:264) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:146) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:342) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:330) at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:535) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:780) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:761) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:745) at hudson.FilePath.act(FilePath.java:842) at hudson.FilePath.act(FilePath.java:824) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:735) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:677) at hudson.model.AbstractProject.checkout(AbstractProject.java:1242) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at
Build failed in Jenkins: Lucene-Core-4x-Beasting #8187
See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8187/ -- Started by timer Building in workspace http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ Cleaning up http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/. Updating https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/lucene ERROR: Failed to update https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/lucene org.tmatesoft.svn.core.SVNException: svn: OPTIONS /repos/asf/lucene/dev/branches/branch_4x/lucene failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:291) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:276) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:264) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:146) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:342) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:330) at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:535) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:780) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:761) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:745) at hudson.FilePath.act(FilePath.java:842) at hudson.FilePath.act(FilePath.java:824) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:735) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:677) at hudson.model.AbstractProject.checkout(AbstractProject.java:1242) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494) at hudson.model.Run.execute(Run.java:1460) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS /repos/asf/lucene/dev/branches/branch_4x/lucene failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89) ... 28 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x/lucene' svn: OPTIONS of /repos/asf/lucene/dev/branches/branch_4x/lucene: 403 Forbidden (https://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:638) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:285) ... 27 more Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x/lucene' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89) at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:366) ... 29 more Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS of /repos/asf/lucene/dev/branches/branch_4x/lucene: 403 Forbidden (https://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:181) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:133) at
Build failed in Jenkins: Lucene-Solr-Robocop #110
See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/110/ -- Started by timer Building in workspace http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/ Cleaning up http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/. Updating https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x ERROR: Failed to update https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:291) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:276) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:264) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:146) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:342) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:330) at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:535) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:780) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:761) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:745) at hudson.FilePath.act(FilePath.java:842) at hudson.FilePath.act(FilePath.java:824) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:735) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:677) at hudson.model.AbstractProject.checkout(AbstractProject.java:1242) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494) at hudson.model.Run.execute(Run.java:1460) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89) ... 28 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: OPTIONS of /repos/asf/lucene/dev/branches/branch_4x: 403 Forbidden (https://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:638) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:285) ... 27 more Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89) at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:366) ... 29 more Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS of /repos/asf/lucene/dev/branches/branch_4x: 403 Forbidden (https://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:181) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:133) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:430) at
Build failed in Jenkins: Lucene-Core-4x-Beasting #8188
See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8188/ -- Started by timer Building in workspace http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ Cleaning up http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/. Updating https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/lucene ERROR: Failed to update https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x/lucene org.tmatesoft.svn.core.SVNException: svn: OPTIONS /repos/asf/lucene/dev/branches/branch_4x/lucene failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:291) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:276) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:264) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:146) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:342) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:330) at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:535) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:780) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:761) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:745) at hudson.FilePath.act(FilePath.java:842) at hudson.FilePath.act(FilePath.java:824) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:735) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:677) at hudson.model.AbstractProject.checkout(AbstractProject.java:1242) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494) at hudson.model.Run.execute(Run.java:1460) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS /repos/asf/lucene/dev/branches/branch_4x/lucene failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89) ... 28 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x/lucene' svn: OPTIONS of /repos/asf/lucene/dev/branches/branch_4x/lucene: 403 Forbidden (https://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:638) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:285) ... 27 more Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x/lucene' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89) at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:366) ... 29 more Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS of /repos/asf/lucene/dev/branches/branch_4x/lucene: 403 Forbidden (https://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:181) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:133) at
Build failed in Jenkins: Lucene-Solr-Robocop #111
See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/111/ -- Started by timer Building in workspace http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/ Cleaning up http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/. Updating https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x ERROR: Failed to update https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:291) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:276) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:264) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:146) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:342) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:330) at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:535) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:780) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:761) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:745) at hudson.FilePath.act(FilePath.java:842) at hudson.FilePath.act(FilePath.java:824) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:735) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:677) at hudson.model.AbstractProject.checkout(AbstractProject.java:1242) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494) at hudson.model.Run.execute(Run.java:1460) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89) ... 28 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: OPTIONS of /repos/asf/lucene/dev/branches/branch_4x: 403 Forbidden (https://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:638) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:285) ... 27 more Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89) at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:366) ... 29 more Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS of /repos/asf/lucene/dev/branches/branch_4x: 403 Forbidden (https://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:181) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:133) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:430) at
Build failed in Jenkins: Lucene-Solr-Robocop #112
See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/112/ -- Started by timer Building in workspace http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/ Cleaning up http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/. Updating https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x ERROR: Failed to update https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x org.tmatesoft.svn.core.SVNException: svn: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:291) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:276) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:264) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.exchangeCapabilities(DAVConnection.java:516) at org.tmatesoft.svn.core.internal.io.dav.DAVConnection.open(DAVConnection.java:98) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.openConnection(DAVRepository.java:1001) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.getRepositoryUUID(DAVRepository.java:146) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:342) at org.tmatesoft.svn.core.wc.SVNBasicClient.createRepository(SVNBasicClient.java:330) at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:535) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:134) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:780) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:761) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:745) at hudson.FilePath.act(FilePath.java:842) at hudson.FilePath.act(FilePath.java:824) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:735) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:677) at hudson.model.AbstractProject.checkout(AbstractProject.java:1242) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494) at hudson.model.Run.execute(Run.java:1460) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:239) Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS /repos/asf/lucene/dev/branches/branch_4x failed at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89) ... 28 more Caused by: org.tmatesoft.svn.core.SVNAuthenticationException: svn: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' svn: OPTIONS of /repos/asf/lucene/dev/branches/branch_4x: 403 Forbidden (https://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:62) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:638) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:285) ... 27 more Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS request failed on '/repos/asf/lucene/dev/branches/branch_4x' at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89) at org.tmatesoft.svn.core.SVNErrorMessage.wrap(SVNErrorMessage.java:366) ... 29 more Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: OPTIONS of /repos/asf/lucene/dev/branches/branch_4x: 403 Forbidden (https://svn.apache.org) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:181) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:133) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.createDefaultErrorMessage(HTTPRequest.java:430) at
Jenkins build is back to normal : Lucene-Core-4x-Beasting #8190
See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8190/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Jenkins build is back to normal : Lucene-Solr-Robocop #113
See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/113/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Build failed in Jenkins: Lucene-Core-4x-Beasting #8125
i can look into this: i dont really know jenkins though. i just started it up to run tests in a loop for additional coverage before the release. On Thu, Sep 20, 2012 at 2:56 AM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: Yup, something is odd. The quit event is the last one emitted from a forked jvm and it should always be received. It'd be great if you could capture the workspace (or just the temporary build files -- **/*.events); I'm sure it's possible to keep these as part of each build -- they're removed on successful completion anyway so it'll affect failed builds only. Could you configure this somehow? Dawid On Thu, Sep 20, 2012 at 2:09 AM, Robert Muir rcm...@gmail.com wrote: this looks like a bug in the testrunner? all tests are actually done executing here. On Wed, Sep 19, 2012 at 8:02 PM, hudsonsevilt...@gmail.com wrote: See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8125/ -- [...truncated 8788 lines...] compile-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: init: compile-lucene-core: compile-codecs: [echo] Building codecs... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: compile-core: compile-core: common.compile-test: install-junit4-taskdef: -clover.disable: -clover.setup: clover: validate: common.test: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/build/memory/test [junit4:junit4] JUnit4 says olá! Master seed: 71BB57BBEF1760E0 [junit4:junit4] Executing 1 suite with 1 JVM. [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.memory.MemoryIndexTest [junit4:junit4] Completed in 3.32s, 5 tests [junit4:junit4] [junit4:junit4] JVM J0: 0.31 .. 4.14 = 3.83s [junit4:junit4] Execution time total: 4.14 sec. [junit4:junit4] Tests summary: 1 suite, 5 tests [echo] 5 slowest tests: [junit4:tophints] 3.32s | org.apache.lucene.index.memory.MemoryIndexTest [echo] Building misc... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: init: -clover.disable: -clover.setup: clover: compile-core: init: test: [echo] Building misc... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: compile-test: [echo] Building misc... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: compile-core: compile-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: init: compile-lucene-core: compile-codecs: [echo] Building codecs... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: compile-core: compile-core: common.compile-test: install-junit4-taskdef: -clover.disable: -clover.setup: clover: validate: common.test: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/build/misc/test [junit4:junit4] JUnit4 says Привет! Master seed: 618B11506A5D [junit4:junit4] Executing 5 suites with 4 JVMs. [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.misc.SweetSpotSimilarityTest [junit4:junit4] Completed on J3 in 0.44s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.index.TestMultiPassIndexSplitter [junit4:junit4] Completed on J3 in 1.32s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.misc.TestHighFreqTerms [junit4:junit4] Completed on J2 in 1.69s, 11 tests [junit4:junit4] [junit4:junit4] Suite:
[jira] [Created] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
Simon Willnauer created LUCENE-4410: --- Summary: Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Priority: Blocker Fix For: 5.0, 4.0 Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-4410: Attachment: LUCENE-4410.patch This patch introduces a FilterStrategy similar to MTQ#RewriteMethod that wraps a given scorer DocIDSet into a Filtered Scorer. By default FilteredQuery uses the RandomAccessFilterStrategy that falls back to leap frog just like FQ did before. In contrast to the current FQ #useRandomAccess is now an impl detail of the RAFilterStrategy and might be removed with a different implementation that might rely on Scorer#cost() or something like that. I also added a DocFirstFilterStrategy that applies filters only iff the delegate scorer matched. This seems more consistent with what other queries do (ie. MTQ) and provides more flexibility to the user Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Priority: Blocker Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Build failed in Jenkins: Lucene-Core-4x-Beasting #8207
See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8207/ -- [...truncated 9786 lines...] [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.spatial.prefix.tree.SpatialPrefixTreeTest [junit4:junit4] Completed on J0 in 0.06s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.spatial.query.SpatialArgsParserTest [junit4:junit4] Completed on J0 in 0.07s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.spatial.vector.TestTwoDoublesStrategy [junit4:junit4] Completed on J3 in 2.49s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.spatial.PortedSolr3Test [junit4:junit4] Completed on J1 in 3.37s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.spatial.prefix.TestRecursivePrefixTreeStrategy [junit4:junit4] Completed on J2 in 3.62s, 4 tests [junit4:junit4] [junit4:junit4] JVM J0: 0.60 .. 2.41 = 1.81s [junit4:junit4] JVM J1: 0.60 .. 4.64 = 4.04s [junit4:junit4] JVM J2: 0.61 .. 5.21 = 4.61s [junit4:junit4] JVM J3: 0.60 .. 4.42 = 3.81s [junit4:junit4] Execution time total: 5.22 sec. [junit4:junit4] Tests summary: 8 suites, 21 tests [echo] 5 slowest tests: [junit4:tophints] 3.62s | org.apache.lucene.spatial.prefix.TestRecursivePrefixTreeStrategy [junit4:tophints] 3.37s | org.apache.lucene.spatial.PortedSolr3Test [junit4:tophints] 2.49s | org.apache.lucene.spatial.vector.TestTwoDoublesStrategy [junit4:tophints] 0.89s | org.apache.lucene.spatial.DistanceStrategyTest [junit4:tophints] 0.73s | org.apache.lucene.spatial.prefix.TestTermQueryPrefixGridStrategy [echo] Building suggest... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: init: -clover.disable: -clover.setup: clover: compile-core: init: test: [echo] Building suggest... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: compile-test: [echo] Building suggest... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: compile-core: compile-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: init: compile-lucene-core: compile-codecs: [echo] Building codecs... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: compile-core: compile-core: common.compile-test: install-junit4-taskdef: -clover.disable: -clover.setup: clover: validate: common.test: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/build/suggest/test [junit4:junit4] JUnit4 says ¡Hola! Master seed: 7C80219B53D8E2AC [junit4:junit4] Executing 17 suites with 4 JVMs. [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.suggest.TestBytesRefList [junit4:junit4] Completed on J2 in 0.46s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spell.TestNGramDistance [junit4:junit4] Completed on J2 in 0.10s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spell.TestJaroWinklerDistance [junit4:junit4] Completed on J2 in 0.05s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.suggest.fst.BytesRefSortersTest [junit4:junit4] Completed on J2 in 0.06s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spell.TestDirectSpellChecker [junit4:junit4] Completed on J3 in 1.49s, 6 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.suggest.PersistenceTest [junit4:junit4] Completed on J3 in 0.18s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spell.TestLuceneDictionary [junit4:junit4] Completed on J3 in 0.38s, 6 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.suggest.fst.FSTCompletionTest [junit4:junit4] Completed on J2 in 2.30s, 12 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.suggest.TestTermFreqIterator [junit4:junit4] Completed on
Re: Build failed in Jenkins: Lucene-Core-4x-Beasting #8207
Sorry for the failed build. we are trying to get this setup so dawid can capture logs in case we encounter the runner crash? from the other day On Thu, Sep 20, 2012 at 6:56 AM, hudsonsevilt...@gmail.com wrote: See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8207/ -- [...truncated 9786 lines...] [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.spatial.prefix.tree.SpatialPrefixTreeTest [junit4:junit4] Completed on J0 in 0.06s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.spatial.query.SpatialArgsParserTest [junit4:junit4] Completed on J0 in 0.07s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.spatial.vector.TestTwoDoublesStrategy [junit4:junit4] Completed on J3 in 2.49s, 3 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.spatial.PortedSolr3Test [junit4:junit4] Completed on J1 in 3.37s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.spatial.prefix.TestRecursivePrefixTreeStrategy [junit4:junit4] Completed on J2 in 3.62s, 4 tests [junit4:junit4] [junit4:junit4] JVM J0: 0.60 .. 2.41 = 1.81s [junit4:junit4] JVM J1: 0.60 .. 4.64 = 4.04s [junit4:junit4] JVM J2: 0.61 .. 5.21 = 4.61s [junit4:junit4] JVM J3: 0.60 .. 4.42 = 3.81s [junit4:junit4] Execution time total: 5.22 sec. [junit4:junit4] Tests summary: 8 suites, 21 tests [echo] 5 slowest tests: [junit4:tophints] 3.62s | org.apache.lucene.spatial.prefix.TestRecursivePrefixTreeStrategy [junit4:tophints] 3.37s | org.apache.lucene.spatial.PortedSolr3Test [junit4:tophints] 2.49s | org.apache.lucene.spatial.vector.TestTwoDoublesStrategy [junit4:tophints] 0.89s | org.apache.lucene.spatial.DistanceStrategyTest [junit4:tophints] 0.73s | org.apache.lucene.spatial.prefix.TestTermQueryPrefixGridStrategy [echo] Building suggest... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: init: -clover.disable: -clover.setup: clover: compile-core: init: test: [echo] Building suggest... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: compile-test: [echo] Building suggest... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: compile-core: compile-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: init: compile-lucene-core: compile-codecs: [echo] Building codecs... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: compile-core: compile-core: common.compile-test: install-junit4-taskdef: -clover.disable: -clover.setup: clover: validate: common.test: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/ws/build/suggest/test [junit4:junit4] JUnit4 says ¡Hola! Master seed: 7C80219B53D8E2AC [junit4:junit4] Executing 17 suites with 4 JVMs. [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.suggest.TestBytesRefList [junit4:junit4] Completed on J2 in 0.46s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spell.TestNGramDistance [junit4:junit4] Completed on J2 in 0.10s, 4 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spell.TestJaroWinklerDistance [junit4:junit4] Completed on J2 in 0.05s, 1 test [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.suggest.fst.BytesRefSortersTest [junit4:junit4] Completed on J2 in 0.06s, 2 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.spell.TestDirectSpellChecker [junit4:junit4] Completed on J3 in 1.49s, 6 tests [junit4:junit4] [junit4:junit4] Suite: org.apache.lucene.search.suggest.PersistenceTest [junit4:junit4] Completed on J3 in 0.18s, 3 tests [junit4:junit4] [junit4:junit4] Suite:
Re: [jira] [Commented] (SOLR-2008) SolrCore.close should shutdown updateHandler before searchExecutor
Well, no code matching the pattern is in SolrCore. Here's the diff:
--- solr/src/java/org/apache/solr/core/SolrCore.java(revision 965937)
+++ solr/src/java/org/apache/solr/core/SolrCore.java(revision 965938)
@@ -690,17 +690,17 @@
SolrException.log(log, e);
}
try {
- closeSearcher();
+ updateHandler.close();
} catch (Exception e) {
SolrException.log(log,e);
}
try {
- searcherExecutor.shutdown();
+ closeSearcher();
} catch (Exception e) {
SolrException.log(log,e);
}
try {
- updateHandler.close();
+ searcherExecutor.shutdown();
} catch (Exception e) {
SolrException.log(log,e);
}
I can't find anything with three trys in a row like this, so one assumes that
subsequent changes refactored this.
Do you have evidence this is still a problem?
Best
Erick
On Thu, Sep 20, 2012 at 12:41 AM, Yandong Yao (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/SOLR-2008?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459331#comment-13459331
]
Yandong Yao commented on SOLR-2008:
---
Just compared solr-4.0-beta source code and diff at
http://mail-archives.apache.org/mod_mbox/lucene-commits/201007.mbox/%3c20100720180640.535952388...@eris.apache.org%3E,
seems the fix in this patch are not in solr-4.0-beta. Please help to check,
thanks!
SolrCore.close should shutdown updateHandler before searchExecutor
--
Key: SOLR-2008
URL: https://issues.apache.org/jira/browse/SOLR-2008
Project: Solr
Issue Type: Bug
Affects Versions: 1.3, 1.4, 1.4.1
Reporter: Hoss Man
Assignee: Hoss Man
Fix For: 3.1, 4.0-ALPHA
As noted on the mailing list...
http://markmail.org/message/cvihm2m6aqhrfbo5
a RejectedExecutionException can occur when shutting down a solr core if the
UpdateHandler.close() wants to do an autocommit - because the searchExecutor
has already been closed.
--
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
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Jenkins build is back to normal : Lucene-Core-4x-Beasting #8208
See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8208/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459522#comment-13459522 ] Michael McCandless commented on LUCENE-4410: This sounds great! I'll look more at the patch ... But surely this is not a blocker issue? We (well, Robert: thanks!) are about to cut the final 4.0 release ... we shouldn't stuff features in at the last minute. Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Priority: Blocker Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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 build is back to normal : Lucene-Core-4x-Beasting #8212
See http://sierranevada.servebeer.com/job/Lucene-Core-4x-Beasting/8212/ - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4409) implement javadocs linting with eclipse ecj compiler
[
https://issues.apache.org/jira/browse/LUCENE-4409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459534#comment-13459534
]
Michael McCandless commented on LUCENE-4409:
Awesome! +1
implement javadocs linting with eclipse ecj compiler
Key: LUCENE-4409
URL: https://issues.apache.org/jira/browse/LUCENE-4409
Project: Lucene - Core
Issue Type: Task
Components: general/build
Reporter: Robert Muir
today we have a lot of custom python scripts checking javadocs (checking for
missing stuff too).
Most of this is implemented by parsing html etc (some of this should stay
this way, like broken-link detection)
But actually the eclipse compiler can do most of this type of linting, and
has a lot of options for it. We can pull it via ivy and run it from the
command-line.
I tested this manually by adding a bogus throws clause to Codec.java,
downloading the ecj.jar from maven and running it manually:
{noformat}
rmuir@beast:~/workspace/lucene-trunk/lucene/core/src/java$ java -cp
~/Downloads/ecj-3.7.2.jar org.eclipse.jdt.internal.compiler.batch.Main
-source 1.6 -d none -enableJavadoc -properties
~/workspace/lucene-trunk/dev-tools/eclipse/.settings/org.eclipse.jdt.core.prefs
.
...
--
120. ERROR in
/home/rmuir/workspace/lucene-trunk/lucene/core/src/java/./org/apache/lucene/codecs/Codec.java
(at line 59)
* @throws IOException */
^^^
Javadoc: Exception IOException is not declared
--
{noformat}
here i specified -d none (don't generate class files), and essentially told
it to read the compiler warnings/errors options set in the dev-tools config.
For javadocs-lint we would want our own separate properties file that
disables the ordinary java warnings (because eclipse can warn/error/ignore on
lots of things, not just javadocs, and does by default).
Separately we could also use this to check/fail/warn on other things besides
javadoc...
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4411) Depth requested in a facetRequest is reset when Sampling is in effect
Gilad Barkai created LUCENE-4411: Summary: Depth requested in a facetRequest is reset when Sampling is in effect Key: LUCENE-4411 URL: https://issues.apache.org/jira/browse/LUCENE-4411 Project: Lucene - Core Issue Type: Bug Components: modules/facet Affects Versions: 3.6.1, 5.0, 4.0 Reporter: Gilad Barkai Attachments: OversampleWithDepthTest.java FacetRequest can be set a Depth parameter, which controls the depth of the result tree to be returned. When Sampling is enabled (and actually used) the Depth parameter gets reset to its default (1). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4411) Depth requested in a facetRequest is reset when Sampling is in effect
[ https://issues.apache.org/jira/browse/LUCENE-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Barkai updated LUCENE-4411: - Attachment: OversampleWithDepthTest.java A Test revealing the bug for Trunk Depth requested in a facetRequest is reset when Sampling is in effect - Key: LUCENE-4411 URL: https://issues.apache.org/jira/browse/LUCENE-4411 Project: Lucene - Core Issue Type: Bug Components: modules/facet Affects Versions: 3.6.1, 5.0, 4.0 Reporter: Gilad Barkai Attachments: OversampleWithDepthTest.java FacetRequest can be set a Depth parameter, which controls the depth of the result tree to be returned. When Sampling is enabled (and actually used) the Depth parameter gets reset to its default (1). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4411) Depth requested in a facetRequest is reset when Sampling is in effect
[ https://issues.apache.org/jira/browse/LUCENE-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Gilad Barkai updated LUCENE-4411: - Attachment: OversampleWithDepthTest.java A Test revealing the bug for 3.6 Depth requested in a facetRequest is reset when Sampling is in effect - Key: LUCENE-4411 URL: https://issues.apache.org/jira/browse/LUCENE-4411 Project: Lucene - Core Issue Type: Bug Components: modules/facet Affects Versions: 3.6.1, 5.0, 4.0 Reporter: Gilad Barkai Attachments: OversampleWithDepthTest.java, OversampleWithDepthTest.java FacetRequest can be set a Depth parameter, which controls the depth of the result tree to be returned. When Sampling is enabled (and actually used) the Depth parameter gets reset to its default (1). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-4410: Priority: Major (was: Blocker) s/blocker/major Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459541#comment-13459541 ] Simon Willnauer commented on LUCENE-4410: - bq. We (well, Robert: thanks!) are about to cut the final 4.0 release ... we shouldn't stuff features in at the last minute. I marked this as a blocker since it really limits to a certain type of filters. I don't think this is a last minute feature really. I'd be totally happy to have only the structural refactoring in Lucene 4.0 and add the DocFirstStrategy later if that is consider a feature though. Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-4411) Depth requested in a facetRequest is reset when Sampling is in effect
[ https://issues.apache.org/jira/browse/LUCENE-4411?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459543#comment-13459543 ] Gilad Barkai commented on LUCENE-4411: -- When sampling is under effect, the original FacetRequest is replaces with a wrapper, which takes under account different sampling related parameters named OverSampledFacetRequest. This wrapping class modifies only a small set of parameters in the request and should otherwise delegate everything to the original one - but it does not. Some of the information that is lost from the original request: SortOrder, SortBy, number of results to lable, ResultMode and Depth. A patch would be available shortly. Depth requested in a facetRequest is reset when Sampling is in effect - Key: LUCENE-4411 URL: https://issues.apache.org/jira/browse/LUCENE-4411 Project: Lucene - Core Issue Type: Bug Components: modules/facet Affects Versions: 3.6.1, 5.0, 4.0 Reporter: Gilad Barkai Attachments: OversampleWithDepthTest.java, OversampleWithDepthTest.java FacetRequest can be set a Depth parameter, which controls the depth of the result tree to be returned. When Sampling is enabled (and actually used) the Depth parameter gets reset to its default (1). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
[
https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459545#comment-13459545
]
Robert Muir commented on LUCENE-4410:
-
I don't agree with blocker either. Should it block 3.6.2 as well? 4.0 is
significantly more flexible than 3.x was.
3.x only had one way to execute a filter: leapfrog.
4.x has three ways: leapfrog, bits, and auto. the default is auto.
{code}
is.search(new FilteredQuery(q,f) {
protected boolean useRandomAccess(Bits bits, int firstFilterDoc) {
return false; // always leapfrog: act like 3.x
}
});
...
is.search(new FilteredQuery(q,f) {
protected boolean useRandomAccess(Bits bits, int firstFilterDoc) {
return true; // never leapfrog if Bits are available
}
});
{code}
Separately (unrelated to release management) I like this idea and I think we
should do it.
But as i said on the mailing list, i think we should be tackling bugs,
javadocs, and tests and approaching stability.
it makes me nervous to add more features to our filter execution right before
release.
Make FilteredQuery more flexible with regards to how filters are applied
Key: LUCENE-4410
URL: https://issues.apache.org/jira/browse/LUCENE-4410
Project: Lucene - Core
Issue Type: Improvement
Components: core/search
Affects Versions: 4.0-BETA
Reporter: Simon Willnauer
Fix For: 5.0, 4.0
Attachments: LUCENE-4410.patch
Currently FilteredQuery uses either the old lucene 3 leap frog approach or
pushes the filter down together with accepted docs. Yet there might be more
strategies required to fit common usecases like geo-filtering where a rather
costly function is applied to each document. Using leap frog this might
result in a very slow query if the filter is advanced since it might have
linear running time to find the next valid document. We should be more
flexible with regards to those usecases and make it possible to either tell
FQ what to do or plug in a strategy that applied a filter in a different way.
The current FQ impl also uses an heuristic to decide if RA or LeapFrog should
be used. This is really an implementation detail of the strategy and not of
FQ and should be moved out.
--
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
Regarding Search
HI Fellows, I had added the following fields in my data-config.xml to implement Data Import Handler dataConfig dataSource driver=org.postgresql.Driver url=jdbc:postgresql://192.168.1.46:5432/evergreen user=postgres / document entity name=page query=SELECT * from actor.usr field column=CUSTID name=custid / field column=FAMILYNAME name=familyname / field column=USRNAME name=usrname / /entity /document /dataConfig When I perform steps of Full import Example at http://wiki.apache.org/solr/DataImportHandler I can successfully index on my database, BUT here the issue is after visiting admin page for search and search for any text, I didn't receive any output and the response is always response lst name=responseHeader int name=status0/int int name=QTime2/int lst name=params str name=indenton/str str name=start0/str str name=qadmin/str str name=version2.2/str str name=rows10/str /lst /lst result name=response numFound=0 start=0/ /response Please guide me on this , am a newbie to apache solr. Thanks, Darshan
[jira] [Commented] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459556#comment-13459556 ] Uwe Schindler commented on LUCENE-4410: --- Hi, I am also against rushing this in with 4.0. There is no slowdown in comparison to Lucene 3.6. My problems are also in the patch: - I hate the crazy not-really-random access Bits impl in the DocFirstStrategy! It is definitely not random access, so it violates the contract. In this case the standard LeapFrog approach should be used (if not random access DocIdSet). - I dont really see an improvement. The Bits interface is not allowed to throw IOException, so the filter should *only* return a Bits interface if its a very fast random access implementation. In all other cases the filter must not suport Bits and then LeapFrog has to be used. - I would only see an improvement if the method Filter.getDocIdSet() is only called after the scorer hit the first document - but this does not work with random access. This was also not done in 3.6, so we should not rush. Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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: Regarding Search
Please ask this question on the user's list, this list is for discussing changes to the code etc. See: http://lucene.apache.org/solr/discussion.html, the Solr User List section. Best Erick On Thu, Sep 20, 2012 at 8:18 AM, darshan dk...@dreamsoftech.com wrote: HI Fellows, I had added the following fields in my data-config.xml to implement Data Import Handler dataConfig dataSource driver=org.postgresql.Driver url=jdbc:postgresql://192.168.1.46:5432/evergreen user=postgres / document entity name=page query=SELECT * from actor.usr field column=CUSTID name=custid / field column=FAMILYNAME name=familyname / field column=USRNAME name=usrname / /entity /document /dataConfig When I perform steps of Full import Example at http://wiki.apache.org/solr/DataImportHandler I can successfully index on my database, BUT here the issue is after visiting admin page for search and search for any text, I didn’t receive any output and the response is always response lst name=responseHeader int name=status0/int int name=QTime2/int lst name=params str name=indenton/str str name=start0/str str name=qadmin/str str name=version2.2/str str name=rows10/str /lst /lst result name=response numFound=0 start=0/ /response Please guide me on this , am a newbie to apache solr. Thanks, Darshan - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459560#comment-13459560 ] Uwe Schindler commented on LUCENE-4410: --- In addition, stuff like this can also be added in later 4.x versions, as it does not change API of FilteredQuery, it just adds an additional ctor param Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459556#comment-13459556 ] Uwe Schindler edited comment on LUCENE-4410 at 9/20/12 11:34 PM: - Hi, I am also against rushing this in with 4.0. There is no slowdown in comparison to Lucene 3.6. My problems are also in the patch: - I hate the crazy not-really-random access Bits impl in the DocFirstStrategy! It is definitely not random access, so it violates the contract. In this case the standard LeapFrog approach should be used (if not random access DocIdSet). - I dont really see an improvement. The Bits interface is not allowed to throw IOException, so the filter should *only* return a Bits interface if its a very fast random access implementation. In all other cases the filter must not suport Bits and then LeapFrog has to be used. - I would only see an improvement if the method Filter.getDocIdSet() is only called after the scorer hit the first document - but this does not work with random access. This was also not done in 3.6, so we should not rush. - The ctor strategy param should never be NULL. The ctor without strategy should pass the explicit one down to this(..., Strategy) was (Author: thetaphi): Hi, I am also against rushing this in with 4.0. There is no slowdown in comparison to Lucene 3.6. My problems are also in the patch: - I hate the crazy not-really-random access Bits impl in the DocFirstStrategy! It is definitely not random access, so it violates the contract. In this case the standard LeapFrog approach should be used (if not random access DocIdSet). - I dont really see an improvement. The Bits interface is not allowed to throw IOException, so the filter should *only* return a Bits interface if its a very fast random access implementation. In all other cases the filter must not suport Bits and then LeapFrog has to be used. - I would only see an improvement if the method Filter.getDocIdSet() is only called after the scorer hit the first document - but this does not work with random access. This was also not done in 3.6, so we should not rush. Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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] [Assigned] (LUCENE-4226) Efficient compression of small to medium stored fields
[
https://issues.apache.org/jira/browse/LUCENE-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand reassigned LUCENE-4226:
Assignee: Adrien Grand
Efficient compression of small to medium stored fields
--
Key: LUCENE-4226
URL: https://issues.apache.org/jira/browse/LUCENE-4226
Project: Lucene - Core
Issue Type: Improvement
Components: core/index
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Trivial
Fix For: 4.1, 5.0
Attachments: CompressionBenchmark.java, CompressionBenchmark.java,
LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch,
SnappyCompressionAlgorithm.java
I've been doing some experiments with stored fields lately. It is very common
for an index with stored fields enabled to have most of its space used by the
.fdt index file. To prevent this .fdt file from growing too much, one option
is to compress stored fields. Although compression works rather well for
large fields, this is not the case for small fields and the compression ratio
can be very close to 100%, even with efficient compression algorithms.
In order to improve the compression ratio for small fields, I've written a
{{StoredFieldsFormat}} that compresses several documents in a single chunk of
data. To see how it behaves in terms of document deserialization speed and
compression ratio, I've run several tests with different index compression
strategies on 100,000 docs from Mike's 1K Wikipedia articles (title and text
were indexed and stored):
- no compression,
- docs compressed with deflate (compression level = 1),
- docs compressed with deflate (compression level = 9),
- docs compressed with Snappy,
- using the compressing {{StoredFieldsFormat}} with deflate (level = 1) and
chunks of 6 docs,
- using the compressing {{StoredFieldsFormat}} with deflate (level = 9) and
chunks of 6 docs,
- using the compressing {{StoredFieldsFormat}} with Snappy and chunks of 6
docs.
For those who don't know Snappy, it is compression algorithm from Google
which has very high compression ratios, but compresses and decompresses data
very quickly.
{noformat}
Format Compression ratio IndexReader.document time
uncompressed 100% 100%
doc/deflate 1 59% 616%
doc/deflate 9 58% 595%
doc/snappy80% 129%
index/deflate 1 49% 966%
index/deflate 9 46% 938%
index/snappy 65% 264%
{noformat}
(doc = doc-level compression, index = index-level compression)
I find it interesting because it allows to trade speed for space (with
deflate, the .fdt file shrinks by a factor of 2, much better than with
doc-level compression). One other interesting thing is that {{index/snappy}}
is almost as compact as {{doc/deflate}} while it is more than 2x faster at
retrieving documents from disk.
These tests have been done on a hot OS cache, which is the worst case for
compressed fields (one can expect better results for formats that have a high
compression ratio since they probably require fewer read/write operations
from disk).
--
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-4226) Efficient compression of small to medium stored fields
[
https://issues.apache.org/jira/browse/LUCENE-4226?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Adrien Grand updated LUCENE-4226:
-
Fix Version/s: 5.0
4.1
Efficient compression of small to medium stored fields
--
Key: LUCENE-4226
URL: https://issues.apache.org/jira/browse/LUCENE-4226
Project: Lucene - Core
Issue Type: Improvement
Components: core/index
Reporter: Adrien Grand
Assignee: Adrien Grand
Priority: Trivial
Fix For: 4.1, 5.0
Attachments: CompressionBenchmark.java, CompressionBenchmark.java,
LUCENE-4226.patch, LUCENE-4226.patch, LUCENE-4226.patch,
SnappyCompressionAlgorithm.java
I've been doing some experiments with stored fields lately. It is very common
for an index with stored fields enabled to have most of its space used by the
.fdt index file. To prevent this .fdt file from growing too much, one option
is to compress stored fields. Although compression works rather well for
large fields, this is not the case for small fields and the compression ratio
can be very close to 100%, even with efficient compression algorithms.
In order to improve the compression ratio for small fields, I've written a
{{StoredFieldsFormat}} that compresses several documents in a single chunk of
data. To see how it behaves in terms of document deserialization speed and
compression ratio, I've run several tests with different index compression
strategies on 100,000 docs from Mike's 1K Wikipedia articles (title and text
were indexed and stored):
- no compression,
- docs compressed with deflate (compression level = 1),
- docs compressed with deflate (compression level = 9),
- docs compressed with Snappy,
- using the compressing {{StoredFieldsFormat}} with deflate (level = 1) and
chunks of 6 docs,
- using the compressing {{StoredFieldsFormat}} with deflate (level = 9) and
chunks of 6 docs,
- using the compressing {{StoredFieldsFormat}} with Snappy and chunks of 6
docs.
For those who don't know Snappy, it is compression algorithm from Google
which has very high compression ratios, but compresses and decompresses data
very quickly.
{noformat}
Format Compression ratio IndexReader.document time
uncompressed 100% 100%
doc/deflate 1 59% 616%
doc/deflate 9 58% 595%
doc/snappy80% 129%
index/deflate 1 49% 966%
index/deflate 9 46% 938%
index/snappy 65% 264%
{noformat}
(doc = doc-level compression, index = index-level compression)
I find it interesting because it allows to trade speed for space (with
deflate, the .fdt file shrinks by a factor of 2, much better than with
doc-level compression). One other interesting thing is that {{index/snappy}}
is almost as compact as {{doc/deflate}} while it is more than 2x faster at
retrieving documents from disk.
These tests have been done on a hot OS cache, which is the worst case for
compressed fields (one can expect better results for formats that have a high
compression ratio since they probably require fewer read/write operations
from disk).
--
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: Regarding Search
On 20 September 2012 17:48, darshan dk...@dreamsoftech.com wrote: HI Fellows, I had added the following fields in my data-config.xml to implement Data Import Handler [...] When I perform steps of Full import Example at http://wiki.apache.org/solr/DataImportHandler The DataImportHandler reports the number of documents successfully indexed. Was this correct? Please provide more details as to the exact URL that you are using for indexing, and your Solr schema. I can successfully index on my database, BUT here the issue is after visiting admin page for search and search for any text, I didn’t receive any output and the response is always If you are indexing properly, the obvious question is do you have any documents that have the text admin. What results do you get when you search for *:* (shorthand for any document) from the Solr admin. interface. Regards, Gora - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Regarding Search
Gora Mohanty :- yes. I have an word admin which is in field usrname. The result on search on indexing database by hitting link :- http://localhost:8983/solr/db/dataimport?command=full-import response lst name=responseHeader int name=status0/int int name=QTime1/int /lst lst name=initArgs lst name=defaults str name=configdb-data-config.xml/str /lst /lst str name=commandfull-import/str str name=statusidle/str str name=importResponse/ lst name=statusMessages str name=Total Requests made to DataSource1/str str name=Total Rows Fetched4/str str name=Total Documents Skipped0/str str name=Full Dump Started2012-09-20 18:28:47/str str name= Indexing completed. Added/Updated: 0 documents. Deleted 0 documents. /str str name=Committed2012-09-20 18:28:48/str str name=Total Documents Processed0/str str name=Time taken0:0:1.404/str /lst str name=WARNING This response format is experimental. It is likely to change in the future. /str /response And Response after hitting url http://localhost:8983/solr/db/admin/ and using *:* to search:- response lst name=responseHeader int name=status0/int int name=QTime2/int lst name=params str name=indenton/str str name=start0/str str name=q*:*/str str name=version2.2/str str name=rows10/str /lst /lst result name=response numFound=0 start=0/ /response Thanks, Darshan -Original Message- From: Gora Mohanty [mailto:g...@mimirtech.com] Sent: Thursday, September 20, 2012 6:13 PM To: dev@lucene.apache.org Subject: Re: Regarding Search On 20 September 2012 17:48, darshan dk...@dreamsoftech.com wrote: HI Fellows, I had added the following fields in my data-config.xml to implement Data Import Handler [...] When I perform steps of Full import Example at http://wiki.apache.org/solr/DataImportHandler The DataImportHandler reports the number of documents successfully indexed. Was this correct? Please provide more details as to the exact URL that you are using for indexing, and your Solr schema. I can successfully index on my database, BUT here the issue is after visiting admin page for search and search for any text, I didn't receive any output and the response is always If you are indexing properly, the obvious question is do you have any documents that have the text admin. What results do you get when you search for *:* (shorthand for any document) from the Solr admin. interface. Regards, Gora - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459583#comment-13459583 ] Uwe Schindler commented on LUCENE-4410: --- I would aggree to this patch if the following is fixed: - remove DocFirst* for now. See above for reasons. - only copy-paste current code in the new API - make the ctor with strategy not accept null, require it to pass an explicit strategy. The ctor without strategy should pass the explicit one down to this(..., Strategy) Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459585#comment-13459585 ] Simon Willnauer commented on LUCENE-4410: - bq. I would aggree to this patch if the following is fixed: I think that is a fair game. I think we should keep the DocFirst for trunk and if everybody agrees I merge the changes into 4.0 excluding the additional strategy. I already just copy pasted the current stuff in the the other two strategies. I can even remove the leap frog strategy in 4.x and keep in on trunk so I can use it to fallback to it in the DocFirst. Objections? Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-2255) local params are not parsed in facet.pivot parameter
[
https://issues.apache.org/jira/browse/SOLR-2255?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459593#comment-13459593
]
Yonik Seeley commented on SOLR-2255:
Looks fine to me. PivotFacet was originally written as a separate component I
think (which I was sort of against) - not sure if that explains any of the
reasoning behind what the code looks like.
local params are not parsed in facet.pivot parameter
Key: SOLR-2255
URL: https://issues.apache.org/jira/browse/SOLR-2255
Project: Solr
Issue Type: New Feature
Affects Versions: 4.0-ALPHA
Reporter: Julien Lirochon
Assignee: David Smiley
Attachments: SOLR-2255_local-param_support_for_pivot_faceting.patch,
SOLR-2255_local-param_support_for_pivot_faceting.patch
...facet=truefacet.pivot={!ex=category}category_id,subcategory_idfq={!tag=category}category_id=42
generates the following error : undefined field {!ex=category}category_id
If you filter on subcategory_id, the facet.pivot result will contain only
results from this subcategory. It's a loss of function since you can't alter
this behavior with local params.
--
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-3860) add ability to split shard to collections API
Yonik Seeley created SOLR-3860: -- Summary: add ability to split shard to collections API Key: SOLR-3860 URL: https://issues.apache.org/jira/browse/SOLR-3860 Project: Solr Issue Type: Sub-task Reporter: Yonik Seeley A split at the collection level should split every shard. -- 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-3733) better organization of javadocs in release
[ https://issues.apache.org/jira/browse/SOLR-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated SOLR-3733: Attachment: SOLR-3733.patch Updated patch because Hoss changed the Solr Tutorial since I uploaded the patch. The Solr tutorial is moved by this patch to the site/html source folder, as it is not related to javadocs at all. By this it can be referenced in consistent way from top-level index.xsl/html file. better organization of javadocs in release -- Key: SOLR-3733 URL: https://issues.apache.org/jira/browse/SOLR-3733 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Attachments: SOLR-3733.patch, SOLR-3733.patch Just an issue to try to improve the stuff mentioned in SOLR-3690. Currently there is one directory api/ which is 'all javadocs' then solrj javadocs are duplicated again under api/solrj now also test-framework is underneath. But this isnt very navigable, and these additional folders (duplicate or not) are hidden behind the index.html on the website. we can improve this and probably generate a landing page from the build.xml descriptions etc like Lucene. -- 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-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459627#comment-13459627 ] Uwe Schindler commented on LUCENE-4410: --- Hi, I have one more comment for the DocFirst strategy: The idea is good because it lets the query drive the collector and we only look up docs, the query hi (using the random access filter). This is sometimes better than passing it down as acceptdocs, because it would slowdown if the Bits interface is expensive and every query subclause must reevaluate the bits.get() method. The problem I had with trhe patch is the crazy Bits implementation for the DocFirstStrategy, which had exactly this problem. Also it was not following the random access pattern, because it allowed the Bits.get() calls only in order. I can easily write a BooleanScorer1-like query that violates this (because a query with more than one sub-clause can easily call Bits.get() out of order for each sub-clause). The DocFirstStrategy wants the query drive the collection, so the non-bits approach should either use LeapFrog (which may be expensive if the filter has ineffective nextDoc()) or it should also implemen DocFirst in order. I would rename that strategy to QueryFirstStrategy and make 2 scorers for it: - a random access one calling Bits.get() for every hit of the query - a sequential one that calls nextDoc() only on the Query, never on the filter. The filter is only advanced to the current query doc. By this the filter oly scans through its docs very seldom (when there is no hit after advance). Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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
Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use?
The Oracle Java Update tool on my Windows PC is pretty insistent that it wants to update my machine to Java 7u7 and REMOVE Java 6. Is it safe to use Java 7u7 for both Lucene Solr development and running Solr yet? My presumption has been that Lucene/Solr still “requires” Java 6. The 4.0 Solr README.txt says to use the Java 6 JDK, but then adds “verify that the Java version is 1.6 or later ”, implying that a later release would be okay. Given that Java 7 will be the “current” release, the README should make some specific statement regarding Java 7. And maybe the top-level README.txt should have a Java version statement – unless both 7 and 6 are fine – although there is a minimum update level that works for 7 and Lucene, right? In any case, clear guidance should be provided. The Solr 4.0 CHANGES.txt does say “You need a Java 1.6 VM or later installed”, suggesting that Java 7 is fine. No mention of Java version requirement in the Lucene CHANGES.txt. I may just manually install 7u7 and not use it to avoid the update notice until Lucene/Solr “upgrades” to Java 7, but I suspect a fair number of people will simply take the update and say goodbye to Java 6. -- Jack Krupansky
RE: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use?
We already stated that in Lucene 3.5/3.6 release note! It’s fine since Java 7u1. There are no news in Lucene 4.0 - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de http://www.thetaphi.de/ eMail: u...@thetaphi.de From: Jack Krupansky [mailto:j...@basetechnology.com] Sent: Thursday, September 20, 2012 4:49 PM To: Lucene/Solr Dev Subject: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use? The Oracle Java Update tool on my Windows PC is pretty insistent that it wants to update my machine to Java 7u7 and REMOVE Java 6. Is it safe to use Java 7u7 for both Lucene Solr development and running Solr yet? My presumption has been that Lucene/Solr still “requires” Java 6. The 4.0 Solr README.txt says to use the Java 6 JDK, but then adds “verify that the Java version is 1.6 or later ”, implying that a later release would be okay. Given that Java 7 will be the “current” release, the README should make some specific statement regarding Java 7. And maybe the top-level README.txt should have a Java version statement – unless both 7 and 6 are fine – although there is a minimum update level that works for 7 and Lucene, right? In any case, clear guidance should be provided. The Solr 4.0 CHANGES.txt does say “You need a Java 1.6 VM or later installed”, suggesting that Java 7 is fine. No mention of Java version requirement in the Lucene CHANGES.txt. I may just manually install 7u7 and not use it to avoid the update notice until Lucene/Solr “upgrades” to Java 7, but I suspect a fair number of people will simply take the update and say goodbye to Java 6. -- Jack Krupansky
[jira] [Updated] (SOLR-3859) SolrCloud admin graph is showing leader as state recovery failed, but it's working
[ https://issues.apache.org/jira/browse/SOLR-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Musil updated SOLR-3859: Attachment: zkDump.txt SolrCloud admin graph is showing leader as state recovery failed, but it's working -- Key: SOLR-3859 URL: https://issues.apache.org/jira/browse/SOLR-3859 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA Environment: linux/centos Reporter: Jim Musil Assignee: Mark Miller Attachments: zkDump.txt I'm not sure this is truly a bug, but the behavior really confuses me. I have four servers running one of my cores. As a test, I took down the leader to watch how leader election works. In this case, a leader was selected, but it went into a state of recovery failed. The odd thing is that everything still works. I can query that box directly and I can query the cluster and I observe correct behavior. -- 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-3859) SolrCloud admin graph is showing leader as state recovery failed, but it's working
[ https://issues.apache.org/jira/browse/SOLR-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459653#comment-13459653 ] Jim Musil commented on SOLR-3859: - Ok, attached. SolrCloud admin graph is showing leader as state recovery failed, but it's working -- Key: SOLR-3859 URL: https://issues.apache.org/jira/browse/SOLR-3859 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA Environment: linux/centos Reporter: Jim Musil Assignee: Mark Miller Attachments: zkDump.txt I'm not sure this is truly a bug, but the behavior really confuses me. I have four servers running one of my cores. As a test, I took down the leader to watch how leader election works. In this case, a leader was selected, but it went into a state of recovery failed. The odd thing is that everything still works. I can query that box directly and I can query the cluster and I observe correct behavior. -- 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-3859) SolrCloud admin graph is showing leader as state recovery failed, but it's working
[ https://issues.apache.org/jira/browse/SOLR-3859?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Jim Musil updated SOLR-3859: Attachment: zkAdminScreen.PNG Here's a screen shot of the admin panel showing three of my cores in this state. All my other cores are fine. SolrCloud admin graph is showing leader as state recovery failed, but it's working -- Key: SOLR-3859 URL: https://issues.apache.org/jira/browse/SOLR-3859 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0-BETA Environment: linux/centos Reporter: Jim Musil Assignee: Mark Miller Attachments: zkAdminScreen.PNG, zkDump.txt I'm not sure this is truly a bug, but the behavior really confuses me. I have four servers running one of my cores. As a test, I took down the leader to watch how leader election works. In this case, a leader was selected, but it went into a state of recovery failed. The odd thing is that everything still works. I can query that box directly and I can query the cluster and I observe correct behavior. -- 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-3733) better organization of javadocs in release
[ https://issues.apache.org/jira/browse/SOLR-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-3733: -- Attachment: SOLR-3733_links.patch patch also adding the links, but there are some problems found by documentation-lint: * dataimporthandler-extras needs to link to dataimporthandler (didnt look at this yet) * some zookeeper confusion because solrj has public classes in the org.apache.zookeeper namespace -- this shoudl be either fixed, or package excluded from javadocs or something * more broken links i didnt look at yet. * my uptodate stuff is not workign, so each contrib is re-docing solrcore and solrj... probably just a typo. this makes it slow. better organization of javadocs in release -- Key: SOLR-3733 URL: https://issues.apache.org/jira/browse/SOLR-3733 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Attachments: SOLR-3733_links.patch, SOLR-3733.patch, SOLR-3733.patch Just an issue to try to improve the stuff mentioned in SOLR-3690. Currently there is one directory api/ which is 'all javadocs' then solrj javadocs are duplicated again under api/solrj now also test-framework is underneath. But this isnt very navigable, and these additional folders (duplicate or not) are hidden behind the index.html on the website. we can improve this and probably generate a landing page from the build.xml descriptions etc like Lucene. -- 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] (PYLUCENE-22) NotImplementedError
goog cheng created PYLUCENE-22: -- Summary: NotImplementedError Key: PYLUCENE-22 URL: https://issues.apache.org/jira/browse/PYLUCENE-22 Project: PyLucene Issue Type: Bug Environment: ubuntu12.04 python2.7 Reporter: goog cheng googcheng@googcheng-TravelMate-4530:~/Downloads/pylucene-3.6.1-2/jcc$ python setup.py build Traceback (most recent call last): File setup.py, line 186, in module enable_shared = patch_setuptools(with_setuptools) File /home/googcheng/Downloads/pylucene-3.6.1-2/jcc/helpers/linux.py, line 67, in patch_setuptools jccdir) NotImplementedError: Shared mode is disabled, setuptools patch.43.0.6c7 must be applied to enable it or the NO_SHARED environment variable must be set to turn off this error. sudo patch -d /usr/local/lib/python2.7/dist-packages/distribute-0.6.26-py2.7.egg -Nup0 /home/googcheng/Downloads/pylucene-3.6.1-2/jcc/jcc/patches/patch.43.0.6c7 See /home/googcheng/Downloads/pylucene-3.6.1-2/jcc/INSTALL for more information about shared mode. -- 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
[jira] [Commented] (SOLR-3733) better organization of javadocs in release
[ https://issues.apache.org/jira/browse/SOLR-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459677#comment-13459677 ] Uwe Schindler commented on SOLR-3733: - I will create a quick branch because Robert and I want to fix this. We will make the linter work and then merge back. better organization of javadocs in release -- Key: SOLR-3733 URL: https://issues.apache.org/jira/browse/SOLR-3733 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Attachments: SOLR-3733_links.patch, SOLR-3733.patch, SOLR-3733.patch Just an issue to try to improve the stuff mentioned in SOLR-3690. Currently there is one directory api/ which is 'all javadocs' then solrj javadocs are duplicated again under api/solrj now also test-framework is underneath. But this isnt very navigable, and these additional folders (duplicate or not) are hidden behind the index.html on the website. we can improve this and probably generate a landing page from the build.xml descriptions etc like Lucene. -- 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-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-4410: Attachment: LUCENE-4410.patch here is a new patch that uses a QueryFirstLeapFrog if we can't pull bits in the DocFirstStrategy. I generalized the LeapFrog scorer such that it can do query first, filter first and filter already advanced I also fixed the parameters in the ctor and added both QUERY_FIRST and FILTER_FIRST strategies to FilterQuery. I hooked that up with Random testing and all tests pass Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch, LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-3733) better organization of javadocs in release
[ https://issues.apache.org/jira/browse/SOLR-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459681#comment-13459681 ] Uwe Schindler commented on SOLR-3733: - I created branch /lucene/dev/branches/solr3733/ in r1388080 better organization of javadocs in release -- Key: SOLR-3733 URL: https://issues.apache.org/jira/browse/SOLR-3733 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Attachments: SOLR-3733_links.patch, SOLR-3733.patch, SOLR-3733.patch Just an issue to try to improve the stuff mentioned in SOLR-3690. Currently there is one directory api/ which is 'all javadocs' then solrj javadocs are duplicated again under api/solrj now also test-framework is underneath. But this isnt very navigable, and these additional folders (duplicate or not) are hidden behind the index.html on the website. we can improve this and probably generate a landing page from the build.xml descriptions etc like Lucene. -- 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: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use?
Okay, that was the one place I hadn’t looked. Thanks. Still, it seems to me that a release should clearly state what it requires, and there is no mention in the 4.0 text files what Java versions are supported, other than the ambiguous references I mentioned. I mean, if someone is starting out with 4.0, why should they have to read the release notes for 3.6?? -- Jack Krupansky From: Uwe Schindler Sent: Thursday, September 20, 2012 10:52 AM To: dev@lucene.apache.org Subject: RE: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use? We already stated that in Lucene 3.5/3.6 release note! It’s fine since Java 7u1. There are no news in Lucene 4.0 - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de From: Jack Krupansky [mailto:j...@basetechnology.com] Sent: Thursday, September 20, 2012 4:49 PM To: Lucene/Solr Dev Subject: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use? The Oracle Java Update tool on my Windows PC is pretty insistent that it wants to update my machine to Java 7u7 and REMOVE Java 6. Is it safe to use Java 7u7 for both Lucene Solr development and running Solr yet? My presumption has been that Lucene/Solr still “requires” Java 6. The 4.0 Solr README.txt says to use the Java 6 JDK, but then adds “verify that the Java version is 1.6 or later ”, implying that a later release would be okay. Given that Java 7 will be the “current” release, the README should make some specific statement regarding Java 7. And maybe the top-level README.txt should have a Java version statement – unless both 7 and 6 are fine – although there is a minimum update level that works for 7 and Lucene, right? In any case, clear guidance should be provided. The Solr 4.0 CHANGES.txt does say “You need a Java 1.6 VM or later installed”, suggesting that Java 7 is fine. No mention of Java version requirement in the Lucene CHANGES.txt. I may just manually install 7u7 and not use it to avoid the update notice until Lucene/Solr “upgrades” to Java 7, but I suspect a fair number of people will simply take the update and say goodbye to Java 6. -- Jack Krupansky
[jira] [Updated] (SOLR-3733) better organization of javadocs in release
[ https://issues.apache.org/jira/browse/SOLR-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-3733: -- Attachment: SOLR-3733_links.patch my buggy patch, but shown just as a difference to Uwe's. better organization of javadocs in release -- Key: SOLR-3733 URL: https://issues.apache.org/jira/browse/SOLR-3733 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Attachments: SOLR-3733_links.patch, SOLR-3733_links.patch, SOLR-3733.patch, SOLR-3733.patch Just an issue to try to improve the stuff mentioned in SOLR-3690. Currently there is one directory api/ which is 'all javadocs' then solrj javadocs are duplicated again under api/solrj now also test-framework is underneath. But this isnt very navigable, and these additional folders (duplicate or not) are hidden behind the index.html on the website. we can improve this and probably generate a landing page from the build.xml descriptions etc like Lucene. -- 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: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use?
BUILD.txt: Lucene Build Instructions Basic steps: 0) Install JDK 1.6 (or greater) On Thu, Sep 20, 2012 at 11:40 AM, Jack Krupansky j...@basetechnology.com wrote: Okay, that was the one place I hadn’t looked. Thanks. Still, it seems to me that a release should clearly state what it requires, and there is no mention in the 4.0 text files what Java versions are supported, other than the ambiguous references I mentioned. I mean, if someone is starting out with 4.0, why should they have to read the release notes for 3.6?? -- Jack Krupansky From: Uwe Schindler Sent: Thursday, September 20, 2012 10:52 AM To: dev@lucene.apache.org Subject: RE: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use? We already stated that in Lucene 3.5/3.6 release note! It’s fine since Java 7u1. There are no news in Lucene 4.0 - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de From: Jack Krupansky [mailto:j...@basetechnology.com] Sent: Thursday, September 20, 2012 4:49 PM To: Lucene/Solr Dev Subject: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use? The Oracle Java Update tool on my Windows PC is pretty insistent that it wants to update my machine to Java 7u7 and REMOVE Java 6. Is it safe to use Java 7u7 for both Lucene Solr development and running Solr yet? My presumption has been that Lucene/Solr still “requires” Java 6. The 4.0 Solr README.txt says to use the Java 6 JDK, but then adds “verify that the Java version is 1.6 or later ”, implying that a later release would be okay. Given that Java 7 will be the “current” release, the README should make some specific statement regarding Java 7. And maybe the top-level README.txt should have a Java version statement – unless both 7 and 6 are fine – although there is a minimum update level that works for 7 and Lucene, right? In any case, clear guidance should be provided. The Solr 4.0 CHANGES.txt does say “You need a Java 1.6 VM or later installed”, suggesting that Java 7 is fine. No mention of Java version requirement in the Lucene CHANGES.txt. I may just manually install 7u7 and not use it to avoid the update notice until Lucene/Solr “upgrades” to Java 7, but I suspect a fair number of people will simply take the update and say goodbye to Java 6. -- Jack Krupansky -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459686#comment-13459686 ] Simon Willnauer commented on LUCENE-4410: - For the given patch I'd commit that to trunk and backport the FilterStrategy structure without the enhancements to 4.0. That way we only have the API change in 4.0 and no new feature but that would allow us to add all the other stuff in this patch to go into 4.1 without breaking anything. Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch, LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459698#comment-13459698 ] Uwe Schindler commented on LUCENE-4410: --- Hi Simon, now I am happy. This is much better than before. I think this is a real improvement, I have no problem with getting that in. Maybe we commit it to trunk first and let it bake over the weekend. PrimaryAdvancedLeapFrogScorer is a good workaround, it take some time until I understaood that this scorer simply already knows that it is already placed on the filter's first doc. Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch, LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459699#comment-13459699 ] Uwe Schindler commented on LUCENE-4410: --- The special PrimaryAdvancedLeapFrogScorer is final, once it is removed, we can make the original one final. For now I would make all methods except the primaryNext() one final (to help Hotspot). Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch, LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-4410: Attachment: LUCENE-4410.patch next iteration, fixing some javadoc issues and adding a changes entry. I also made all methods that should not be subclassed final on LeapFrogScorer so hotspot doesn´t mess around with it. I think its ready. If nobody objects I will commit this to trunk tomorrow morning Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch, LUCENE-4410.patch, LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459702#comment-13459702 ] Michael McCandless commented on LUCENE-4410: I think we should target 4.1 for this? Ie commit to trunk, let it back, ship 4.0, backport. Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch, LUCENE-4410.patch, LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459703#comment-13459703 ] Uwe Schindler commented on LUCENE-4410: --- We can only do this, if we add experimental to the random access detetion method... Otherwise we are in backwards-compatibility hell in 4.1 I checked the code, it's identical to the one before, just class hierarchy changed... We can maybe only remove the new QueryFirstStrategy, but the other one is 100% identical to current 4.0 code. I see no problem with it going in. Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch, LUCENE-4410.patch, LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459709#comment-13459709 ] Uwe Schindler commented on LUCENE-4410: --- Simon: I dont see the final methods in latest patch. Are you sure you uploaded the right one? Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch, LUCENE-4410.patch, LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use?
Thanks, but I was under the impression that there was a release of 1.7 that did not work properly with Lucene. Or, was there a workaround in a subsequent release of Lucene so that Lucene/Solr (3.6, 3.6.1, 4.0, 5.0) now works with even that early Java 7 release that failed with earlier releases of Lucene/Solr? -- Jack Krupansky -Original Message- From: Robert Muir Sent: Thursday, September 20, 2012 11:45 AM To: dev@lucene.apache.org Subject: Re: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use? BUILD.txt: Lucene Build Instructions Basic steps: 0) Install JDK 1.6 (or greater) On Thu, Sep 20, 2012 at 11:40 AM, Jack Krupansky j...@basetechnology.com wrote: Okay, that was the one place I hadn’t looked. Thanks. Still, it seems to me that a release should clearly state what it requires, and there is no mention in the 4.0 text files what Java versions are supported, other than the ambiguous references I mentioned. I mean, if someone is starting out with 4.0, why should they have to read the release notes for 3.6?? -- Jack Krupansky From: Uwe Schindler Sent: Thursday, September 20, 2012 10:52 AM To: dev@lucene.apache.org Subject: RE: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use? We already stated that in Lucene 3.5/3.6 release note! It’s fine since Java 7u1. There are no news in Lucene 4.0 - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de From: Jack Krupansky [mailto:j...@basetechnology.com] Sent: Thursday, September 20, 2012 4:49 PM To: Lucene/Solr Dev Subject: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use? The Oracle Java Update tool on my Windows PC is pretty insistent that it wants to update my machine to Java 7u7 and REMOVE Java 6. Is it safe to use Java 7u7 for both Lucene Solr development and running Solr yet? My presumption has been that Lucene/Solr still “requires” Java 6. The 4.0 Solr README.txt says to use the Java 6 JDK, but then adds “verify that the Java version is 1.6 or later ”, implying that a later release would be okay. Given that Java 7 will be the “current” release, the README should make some specific statement regarding Java 7. And maybe the top-level README.txt should have a Java version statement – unless both 7 and 6 are fine – although there is a minimum update level that works for 7 and Lucene, right? In any case, clear guidance should be provided. The Solr 4.0 CHANGES.txt does say “You need a Java 1.6 VM or later installed”, suggesting that Java 7 is fine. No mention of Java version requirement in the Lucene CHANGES.txt. I may just manually install 7u7 and not use it to avoid the update notice until Lucene/Solr “upgrades” to Java 7, but I suspect a fair number of people will simply take the update and say goodbye to Java 6. -- Jack Krupansky -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459715#comment-13459715 ] Michael McCandless commented on LUCENE-4410: bq. We can only do this, if we add experimental to the random access detetion method... +1 I just don't think we should be making such biggish changes just before releasing 4.0... Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch, LUCENE-4410.patch, LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use?
No Oracle fixed the problem in 7u1, see http://blog.thetaphi.de/2011/10/java-7-update-1-released-does-it-fix.html If you use Java 7 GA then your index is corru(m)pt in milliseconds :-) - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Jack Krupansky [mailto:j...@basetechnology.com] Sent: Thursday, September 20, 2012 6:26 PM To: dev@lucene.apache.org Subject: Re: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use? Thanks, but I was under the impression that there was a release of 1.7 that did not work properly with Lucene. Or, was there a workaround in a subsequent release of Lucene so that Lucene/Solr (3.6, 3.6.1, 4.0, 5.0) now works with even that early Java 7 release that failed with earlier releases of Lucene/Solr? -- Jack Krupansky -Original Message- From: Robert Muir Sent: Thursday, September 20, 2012 11:45 AM To: dev@lucene.apache.org Subject: Re: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use? BUILD.txt: Lucene Build Instructions Basic steps: 0) Install JDK 1.6 (or greater) On Thu, Sep 20, 2012 at 11:40 AM, Jack Krupansky j...@basetechnology.com wrote: Okay, that was the one place I hadn’t looked. Thanks. Still, it seems to me that a release should clearly state what it requires, and there is no mention in the 4.0 text files what Java versions are supported, other than the ambiguous references I mentioned. I mean, if someone is starting out with 4.0, why should they have to read the release notes for 3.6?? -- Jack Krupansky From: Uwe Schindler Sent: Thursday, September 20, 2012 10:52 AM To: dev@lucene.apache.org Subject: RE: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use? We already stated that in Lucene 3.5/3.6 release note! It’s fine since Java 7u1. There are no news in Lucene 4.0 - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de From: Jack Krupansky [mailto:j...@basetechnology.com] Sent: Thursday, September 20, 2012 4:49 PM To: Lucene/Solr Dev Subject: Is it safe to upgrade to Oracle Java 7u7 for Lucene/Solr development and use? The Oracle Java Update tool on my Windows PC is pretty insistent that it wants to update my machine to Java 7u7 and REMOVE Java 6. Is it safe to use Java 7u7 for both Lucene Solr development and running Solr yet? My presumption has been that Lucene/Solr still “requires” Java 6. The 4.0 Solr README.txt says to use the Java 6 JDK, but then adds “verify that the Java version is 1.6 or later ”, implying that a later release would be okay. Given that Java 7 will be the “current” release, the README should make some specific statement regarding Java 7. And maybe the top-level README.txt should have a Java version statement – unless both 7 and 6 are fine – although there is a minimum update level that works for 7 and Lucene, right? In any case, clear guidance should be provided. The Solr 4.0 CHANGES.txt does say “You need a Java 1.6 VM or later installed”, suggesting that Java 7 is fine. No mention of Java version requirement in the Lucene CHANGES.txt. I may just manually install 7u7 and not use it to avoid the update notice until Lucene/Solr “upgrades” to Java 7, but I suspect a fair number of people will simply take the update and say goodbye to Java 6. -- Jack Krupansky -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4410) Make FilteredQuery more flexible with regards to how filters are applied
[ https://issues.apache.org/jira/browse/LUCENE-4410?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459721#comment-13459721 ] Uwe Schindler commented on LUCENE-4410: --- It is not biggish :-) It is same code as before :-) I don't care, but the RA autodetection was always horrible to me, now its hidden behind something else! Make FilteredQuery more flexible with regards to how filters are applied Key: LUCENE-4410 URL: https://issues.apache.org/jira/browse/LUCENE-4410 Project: Lucene - Core Issue Type: Improvement Components: core/search Affects Versions: 4.0-BETA Reporter: Simon Willnauer Fix For: 5.0, 4.0 Attachments: LUCENE-4410.patch, LUCENE-4410.patch, LUCENE-4410.patch Currently FilteredQuery uses either the old lucene 3 leap frog approach or pushes the filter down together with accepted docs. Yet there might be more strategies required to fit common usecases like geo-filtering where a rather costly function is applied to each document. Using leap frog this might result in a very slow query if the filter is advanced since it might have linear running time to find the next valid document. We should be more flexible with regards to those usecases and make it possible to either tell FQ what to do or plug in a strategy that applied a filter in a different way. The current FQ impl also uses an heuristic to decide if RA or LeapFrog should be used. This is really an implementation detail of the strategy and not of FQ and should be moved out. -- 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-3857) DIH: SqlEntityProcessor with simple cache broken
[
https://issues.apache.org/jira/browse/SOLR-3857?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459727#comment-13459727
]
James Dyer commented on SOLR-3857:
--
Mikhail,
Based on reading the wiki, I imagine the purpose would be if the child entity
was a lookup table where not all the keys were used but some of the keys join
to many parent rows. This would save it from having to read and cache the
entire table if not the whole table is needed. Also, it would prevent any key
from being read more than once from the db.
This sounds like a very narrow use-case and I'm tempted to say that this
feature is removed in 4.0 (and was broken in 3.6)! On the other hand, someone
somewhere is probably using it and its very much technically feasible. So I'd
hate to take away something just because the first implementation was poor and
re-implementing it would be a little work. Then again, if it depends on me to
be fixing this, I'm not so sure it'll be ready for 4.0...
I also still have significant test-case re-writing yet to do so who knows what
other bugs I can find doing that. Hopefully no more but I have seen sporatic
complaints from users that 3.6/4.0 isn't working exactly like 3.5 and prior.
DIH: SqlEntityProcessor with simple cache broken
--
Key: SOLR-3857
URL: https://issues.apache.org/jira/browse/SOLR-3857
Project: Solr
Issue Type: Bug
Affects Versions: 3.6.1, 4.0-BETA
Reporter: James Dyer
The wiki describes a usage of CachedSqlEntityProcessor like this:
{code:xml}
entity name=y query=select * from y where xid=${x.id}
processor=CachedSqlEntityProcessor
{code}
This creates what the code refers as a simple cache. Rather than build the
entire cache up-front, the cache is built on-the-go. I think this has
limited use cases but it would be nice to preserve the feature if possible.
Unfortunately this was not included in any (effective) unit tests, and
SOLR-2382 entirely broke the functionality for 3.6/4.0-alpha+ . At a first
glance, the fix may not be entirely straightforward.
This was found while writing tests for SOLR-3856.
--
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: Regarding Search
On 20/09/2012, darshan dk...@dreamsoftech.com wrote: [...] The result on search on indexing database by hitting link :- http://localhost:8983/solr/db/dataimport?command=full-import [...] str name=Total Requests made to DataSource1/str str name=Total Rows Fetched4/str str name=Total Documents Skipped0/str str name=Full Dump Started2012-09-20 18:28:47/str str name= Indexing completed. Added/Updated: 0 documents. Deleted 0 documents. [...] There is your problem right there. No documents were added to the Solr index, though four rows were fetched. To try to figure out why, please share with us your schema.xml. Try out the query directly against the database to see what exactly is fetched. Also, I would check the column names in your database, and the field names in your DIH config. file: The case of the names matters. Regards, Gora - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
Hoss Man created SOLR-3861: -- Summary: regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-BETA, 4.0-ALPHA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.0 SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- 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-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
[ https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459789#comment-13459789 ] Hoss Man commented on SOLR-3861: mark: can you please sanity check whether this was an intentional change or a fluke? is the original risk in SOLR-2008 now eliminated by some other change to how the UpdateHandler is used? regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor --- Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 4.0-BETA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.0 SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- 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-3825) Log document IDs when they are retrieved
[ https://issues.apache.org/jira/browse/SOLR-3825?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-3825. Resolution: Fixed Fix Version/s: 4.0 Grant committed to trunk earlier, I just backported to 4x: http://svn.apache.org/viewvc?rev=1388136view=rev Log document IDs when they are retrieved Key: SOLR-3825 URL: https://issues.apache.org/jira/browse/SOLR-3825 Project: Solr Issue Type: Improvement Components: SearchComponents - other Reporter: Scott Stults Assignee: Grant Ingersoll Priority: Trivial Fix For: 4.0 Attachments: SOLR-3825.1.patch, SOLR-3825.patch During relevancy tuning it's important to know exactly which documents the client has seen. Right now the only way to get that list is to splice into the HTTP traffic. Preferably the IDs could be logged along with the query. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Build failed in Jenkins: Lucene-Solr-Robocop #181
See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/181/changes Changes: [yonik] SOLR-3825: Added optional capability to log what ids are in a response -- Started by timer Started by timer Started by timer Started by timer Started by timer Started by timer Started by timer Started by timer Building in workspace http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/ Cleaning up http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/. Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/build Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/test-framework/lib/ant-1.8.2.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/test-framework/lib/junit-4.10.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/test-framework/lib/junit4-ant-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/test-framework/lib/randomizedtesting-runner-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/spatial/lib/spatial4j-0.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/sandbox/lib/jakarta-regexp-1.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/tools/lib/asm-debug-all-4.0.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/phonetic/lib/commons-codec-1.7.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/uima/lib/Tagger-2.3.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/uima/lib/WhitespaceTokenizer-2.3.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/uima/lib/uimaj-core-2.3.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/icu/lib/icu4j-49.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/morfologik/lib/morfologik-fsa-1.5.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/morfologik/lib/morfologik-polish-1.5.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/morfologik/lib/morfologik-stemming-1.5.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/demo/lib/servlet-api-2.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/benchmark/lib/commons-compress-1.4.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/benchmark/lib/nekohtml-1.9.15.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/benchmark/lib/xercesImpl-2.9.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/build Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/test-framework/lib/ant-1.8.2.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/test-framework/lib/junit-4.10.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/test-framework/lib/junit4-ant-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/test-framework/lib/randomizedtesting-runner-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/commons-io-2.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/httpclient-4.1.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/httpcore-4.1.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/httpmime-4.1.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/jcl-over-slf4j-1.6.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/log4j-over-slf4j-1.6.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/slf4j-api-1.6.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/slf4j-jdk14-1.6.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/wstx-asl-3.2.7.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/zookeeper-3.3.6.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/example/start.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/example/example-DIH/solr/db/lib/hsqldb-1.8.0.10.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/example/lib/jetty-continuation-8.1.2.v20120308.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/example/lib/jetty-deploy-8.1.2.v20120308.jar Deleting
Build failed in Jenkins: Lucene-Solr-Robocop #182
See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/182/ -- Started by timer Started by timer Started by timer Started by timer Started by timer Building in workspace http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/ Cleaning up http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/. Updating https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x At revision 1388142 no change for https://svn.apache.org/repos/asf/lucene/dev/branches/branch_4x since the previous build [Lucene-Solr-Robocop] $ ant precommit Buildfile: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/build.xml check-svn-working-copy: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: Ivy 2.2.0 - 20100923230623 :: http://ant.apache.org/ivy/ :: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml check-svn-working-copy: [ivy:cachepath] :: resolving dependencies :: org.tmatesoft.svnkit#svnkit-caller;working [ivy:cachepath] confs: [default] [ivy:cachepath] found org.tmatesoft.svnkit#svnkit;1.7.5-v1 in public [ivy:cachepath] found de.regnis.q.sequence#sequence-library;1.0.2 in public [ivy:cachepath] found net.java.dev.jna#jna;3.4.0 in public [ivy:cachepath] found org.tmatesoft.sqljet#sqljet;1.1.4 in public [ivy:cachepath] found org.antlr#antlr-runtime;3.4 in public [ivy:cachepath] found com.trilead#trilead-ssh2;1.0.0-build215 in public [ivy:cachepath] :: resolution report :: resolve 151ms :: artifacts dl 5ms - | |modules|| artifacts | | conf | number| search|dwnlded|evicted|| number|dwnlded| - | default | 6 | 0 | 0 | 0 || 6 | 0 | - [svn] Getting all versioned and unversioned files... [svn] Filtering files with existing svn:eol-style... [svn] Filtering files with binary svn:mime-type... BUILD FAILED http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/build.xml:295: The following error occurred while executing this line: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/extra-targets.xml:118: The following files are missing svn:eol-style (or binary svn:mime-type): * solr/core/src/java/org/apache/solr/handler/component/ResponseLogComponent.java * solr/core/src/test-files/solr/collection1/conf/solrconfig-response-log-component.xml * solr/core/src/test/org/apache/solr/handler/component/ResponseLogComponentTest.java Total time: 5 seconds Build step 'Invoke Ant' marked build as failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Build failed in Jenkins: Lucene-Solr-Robocop #181
On Thu, Sep 20, 2012 at 1:56 PM, hudsonsevilt...@gmail.com wrote: See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/181/changes Changes: [yonik] SOLR-3825: Added optional capability to log what ids are in a response -- Started by timer Started by timer Started by timer Started by timer Started by timer Started by timer Started by timer Started by timer Building in workspace http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/ Cleaning up http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/. Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/build Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/test-framework/lib/ant-1.8.2.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/test-framework/lib/junit-4.10.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/test-framework/lib/junit4-ant-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/test-framework/lib/randomizedtesting-runner-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/spatial/lib/spatial4j-0.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/sandbox/lib/jakarta-regexp-1.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/tools/lib/asm-debug-all-4.0.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/phonetic/lib/commons-codec-1.7.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/uima/lib/Tagger-2.3.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/uima/lib/WhitespaceTokenizer-2.3.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/uima/lib/uimaj-core-2.3.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/icu/lib/icu4j-49.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/morfologik/lib/morfologik-fsa-1.5.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/morfologik/lib/morfologik-polish-1.5.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/analysis/morfologik/lib/morfologik-stemming-1.5.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/demo/lib/servlet-api-2.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/benchmark/lib/commons-compress-1.4.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/benchmark/lib/nekohtml-1.9.15.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./lucene/benchmark/lib/xercesImpl-2.9.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/build Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/test-framework/lib/ant-1.8.2.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/test-framework/lib/junit-4.10.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/test-framework/lib/junit4-ant-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/test-framework/lib/randomizedtesting-runner-2.0.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/commons-io-2.1.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/httpclient-4.1.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/httpcore-4.1.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/httpmime-4.1.3.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/jcl-over-slf4j-1.6.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/log4j-over-slf4j-1.6.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/slf4j-api-1.6.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/slf4j-jdk14-1.6.4.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/wstx-asl-3.2.7.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/solrj/lib/zookeeper-3.3.6.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/example/start.jar Deleting http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/./solr/example/example-DIH/solr/db/lib/hsqldb-1.8.0.10.jar Deleting
Jenkins build is back to normal : Lucene-Solr-Robocop #183
See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/183/changes - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3862) add remove as update option for atomically removing a value from a multivalued field
Jim Musil created SOLR-3862: --- Summary: add remove as update option for atomically removing a value from a multivalued field Key: SOLR-3862 URL: https://issues.apache.org/jira/browse/SOLR-3862 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-BETA Reporter: Jim Musil Currently you can atomically add a value to a multivalued field. It would be useful to be able to remove a value from a multivalued field. When you set a multivalued field to null, it destroys all values. -- 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-3861) regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor
[ https://issues.apache.org/jira/browse/SOLR-3861?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459871#comment-13459871 ] Sami Siren commented on SOLR-3861: -- Not sure if this is related but the famous TestReplicationHandler failures seem to throw the mentioned RejectedExecutionException when the test fails. for example here: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/1221/ regresion of SOLR-2008 - updateHandler should be closed before searcherExecutor --- Key: SOLR-3861 URL: https://issues.apache.org/jira/browse/SOLR-3861 Project: Solr Issue Type: Bug Affects Versions: 4.0-ALPHA, 4.0-BETA Reporter: Hoss Man Assignee: Mark Miller Priority: Blocker Fix For: 4.0 SOLR-2008 fixed a possible RejectedExecutionException by ensuring that SolrCore closed the updateHandler before the searcherExecutor. [~markrmil...@gmail.com] re-flipped this logic in r1159378, which is annotated as fixing both SOLR-2654 and SOLR-2654 (dup typo i guess) but it's not clear why - pretty sure this means that the risk of a Rejected exception is back in 4.0-BETA... https://svn.apache.org/viewvc/lucene/dev/trunk/solr/core/src/java/org/apache/solr/core/SolrCore.java?r1=1146905r2=1159378 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Build failed in Jenkins: Lucene-Solr-4x-ReleaseSmoke #1
See http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/1/ -- [...truncated 15330 lines...] [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.sandbox.queries... [javadoc] Loading source files for package org.apache.lucene.sandbox.queries.regex... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/docs/sandbox/help-doc.html... [javadoc] Note: Custom tags that were not seen: @lucene.internal, @lucene.experimental [exec] Result: 1 [jar] Building jar: http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/sandbox/lucene-sandbox-4.0-javadoc.jar [echo] Building spatial... check-queries-javadocs-uptodate: javadocs-queries: check-queries-uptodate: jar-queries: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: common.compile-core: compile-core: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/docs/spatial [echo] Building spatial... download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/docs/spatial [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.spatial... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix.tree... [javadoc] Loading source files for package org.apache.lucene.spatial.query... [javadoc] Loading source files for package org.apache.lucene.spatial.util... [javadoc] Loading source files for package org.apache.lucene.spatial.vector... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [exec] Result: 1 [jar] Building jar: http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/spatial/lucene-spatial-4.0-javadoc.jar [echo] Building suggest... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: compile-core: check-lucene-core-javadocs-uptodate: javadocs-lucene-core: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/docs/suggest [echo] Building suggest... download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/docs/suggest [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.search.spell... [javadoc] Loading source files for package org.apache.lucene.search.suggest... [javadoc] Loading source files for package org.apache.lucene.search.suggest.fst... [javadoc] Loading source files for package org.apache.lucene.search.suggest.jaspell... [javadoc] Loading source files for package org.apache.lucene.search.suggest.tst... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [exec] Result: 1 [jar] Building jar: http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/suggest/lucene-suggest-4.0-javadoc.jar check-lucene-test-framework-javadocs-uptodate: javadocs-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/ivy-settings.xml resolve: init: check-lucene-core-javadocs-uptodate: javadocs-lucene-core: check-lucene-codecs-javadocs-uptodate: javadocs-lucene-codecs: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/docs/test-framework download-java6-javadoc-packagelist:
Re: Build failed in Jenkins: Lucene-Solr-4x-ReleaseSmoke #1
This has something to do with jenkins' crazy broken internal svn i think. I'll disable this job until I can figure out how to make it work On Thu, Sep 20, 2012 at 4:20 PM, hudsonsevilt...@gmail.com wrote: See http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/1/ -- [...truncated 15330 lines...] [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.sandbox.queries... [javadoc] Loading source files for package org.apache.lucene.sandbox.queries.regex... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [javadoc] Generating http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/docs/sandbox/help-doc.html... [javadoc] Note: Custom tags that were not seen: @lucene.internal, @lucene.experimental [exec] Result: 1 [jar] Building jar: http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/sandbox/lucene-sandbox-4.0-javadoc.jar [echo] Building spatial... check-queries-javadocs-uptodate: javadocs-queries: check-queries-uptodate: jar-queries: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: common.compile-core: compile-core: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/docs/spatial [echo] Building spatial... download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/docs/spatial [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.spatial... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix.tree... [javadoc] Loading source files for package org.apache.lucene.spatial.query... [javadoc] Loading source files for package org.apache.lucene.spatial.util... [javadoc] Loading source files for package org.apache.lucene.spatial.vector... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [exec] Result: 1 [jar] Building jar: http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/spatial/lucene-spatial-4.0-javadoc.jar [echo] Building suggest... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/ivy-settings.xml resolve: common.init: compile-lucene-core: init: -clover.disable: -clover.setup: clover: compile-core: check-lucene-core-javadocs-uptodate: javadocs-lucene-core: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/docs/suggest [echo] Building suggest... download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/docs/suggest [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.search.spell... [javadoc] Loading source files for package org.apache.lucene.search.suggest... [javadoc] Loading source files for package org.apache.lucene.search.suggest.fst... [javadoc] Loading source files for package org.apache.lucene.search.suggest.jaspell... [javadoc] Loading source files for package org.apache.lucene.search.suggest.tst... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [exec] Result: 1 [jar] Building jar: http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/build/suggest/lucene-suggest-4.0-javadoc.jar check-lucene-test-framework-javadocs-uptodate: javadocs-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-4x-ReleaseSmoke/ws/lucene/ivy-settings.xml
[jira] [Commented] (SOLR-3862) add remove as update option for atomically removing a value from a multivalued field
[ https://issues.apache.org/jira/browse/SOLR-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459912#comment-13459912 ] Otis Gospodnetic commented on SOLR-3862: I *think* [~mgarski] and somebody else have a separate, existing JIRA issue for this... add remove as update option for atomically removing a value from a multivalued field -- Key: SOLR-3862 URL: https://issues.apache.org/jira/browse/SOLR-3862 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-BETA Reporter: Jim Musil Currently you can atomically add a value to a multivalued field. It would be useful to be able to remove a value from a multivalued field. When you set a multivalued field to null, it destroys all values. -- 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-3862) add remove as update option for atomically removing a value from a multivalued field
[ https://issues.apache.org/jira/browse/SOLR-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13459915#comment-13459915 ] Michael Garski commented on SOLR-3862: -- I believe you may be thinking of someone else Otis - I have not done anything with updatable fields. add remove as update option for atomically removing a value from a multivalued field -- Key: SOLR-3862 URL: https://issues.apache.org/jira/browse/SOLR-3862 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-BETA Reporter: Jim Musil Currently you can atomically add a value to a multivalued field. It would be useful to be able to remove a value from a multivalued field. When you set a multivalued field to null, it destroys all values. -- 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-3862) add remove as update option for atomically removing a value from a multivalued field
[ https://issues.apache.org/jira/browse/SOLR-3862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460051#comment-13460051 ] Hoss Man commented on SOLR-3862: something to consider is the semantics: should it be remove by position in the list, or should it be remove by value and if it's remove by value then what happens if the value occurs multiple times in the list? add remove as update option for atomically removing a value from a multivalued field -- Key: SOLR-3862 URL: https://issues.apache.org/jira/browse/SOLR-3862 Project: Solr Issue Type: Improvement Components: SolrCloud Affects Versions: 4.0-BETA Reporter: Jim Musil Currently you can atomically add a value to a multivalued field. It would be useful to be able to remove a value from a multivalued field. When you set a multivalued field to null, it destroys all values. -- 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-3733) better organization of javadocs in release
[ https://issues.apache.org/jira/browse/SOLR-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13460055#comment-13460055 ] Uwe Schindler commented on SOLR-3733: - Committed trunk revision: 1388271 better organization of javadocs in release -- Key: SOLR-3733 URL: https://issues.apache.org/jira/browse/SOLR-3733 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Attachments: SOLR-3733_links.patch, SOLR-3733_links.patch, SOLR-3733.patch, SOLR-3733.patch, SOLR-3733.patch Just an issue to try to improve the stuff mentioned in SOLR-3690. Currently there is one directory api/ which is 'all javadocs' then solrj javadocs are duplicated again under api/solrj now also test-framework is underneath. But this isnt very navigable, and these additional folders (duplicate or not) are hidden behind the index.html on the website. we can improve this and probably generate a landing page from the build.xml descriptions etc like Lucene. -- 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-3733) better organization of javadocs in release
[ https://issues.apache.org/jira/browse/SOLR-3733?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved SOLR-3733. - Resolution: Fixed Fix Version/s: 5.0 4.0 Assignee: Uwe Schindler Committed to 4.x at revision: 1388275 Thanks Robert Hoss! better organization of javadocs in release -- Key: SOLR-3733 URL: https://issues.apache.org/jira/browse/SOLR-3733 Project: Solr Issue Type: Task Components: Build Reporter: Robert Muir Assignee: Uwe Schindler Fix For: 4.0, 5.0 Attachments: SOLR-3733_links.patch, SOLR-3733_links.patch, SOLR-3733.patch, SOLR-3733.patch, SOLR-3733.patch Just an issue to try to improve the stuff mentioned in SOLR-3690. Currently there is one directory api/ which is 'all javadocs' then solrj javadocs are duplicated again under api/solrj now also test-framework is underneath. But this isnt very navigable, and these additional folders (duplicate or not) are hidden behind the index.html on the website. we can improve this and probably generate a landing page from the build.xml descriptions etc like Lucene. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Build failed in Jenkins: Lucene-Solr-Robocop #204
See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/204/changes Changes: [uschindler] Merged SOLR-3733: better organization of javadocs in release [hossman] blurb+link about other possibility of other codecs (merge r1388260) -- [...truncated 16229 lines...] common.init: compile-lucene-core: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml resolve: init: -clover.disable: -clover.setup: clover: compile-core: init: -clover.disable: -clover.setup: clover: common.compile-core: compile-core: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/spatial [echo] Building spatial... download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/spatial [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.spatial... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix.tree... [javadoc] Loading source files for package org.apache.lucene.spatial.query... [javadoc] Loading source files for package org.apache.lucene.spatial.util... [javadoc] Loading source files for package org.apache.lucene.spatial.vector... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [exec] Result: 1 [jar] Building jar: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/spatial/lucene-spatial-4.0-SNAPSHOT-javadoc.jar [echo] Building suggest... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml resolve: common.init: compile-lucene-core: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml resolve: init: -clover.disable: -clover.setup: clover: compile-core: init: -clover.disable: -clover.setup: clover: compile-core: check-lucene-core-javadocs-uptodate: javadocs-lucene-core: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/suggest [echo] Building suggest... download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/suggest [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.search.spell... [javadoc] Loading source files for package org.apache.lucene.search.suggest... [javadoc] Loading source files for package org.apache.lucene.search.suggest.fst... [javadoc] Loading source files for package org.apache.lucene.search.suggest.jaspell... [javadoc] Loading source files for package org.apache.lucene.search.suggest.tst... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [exec] Result: 1 [jar] Building jar: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/suggest/lucene-suggest-4.0-SNAPSHOT-javadoc.jar check-lucene-test-framework-javadocs-uptodate: javadocs-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml resolve: init: check-lucene-core-javadocs-uptodate: javadocs-lucene-core: check-lucene-codecs-javadocs-uptodate: javadocs-lucene-codecs: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/test-framework download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/test-framework [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.codecs.asserting... [javadoc] Loading source files for package org.apache.lucene.codecs.bloom... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package
Re: Build failed in Jenkins: Lucene-Solr-Robocop #204
I committed a fix On Thu, Sep 20, 2012 at 8:06 PM, hudsonsevilt...@gmail.com wrote: See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/204/changes Changes: [uschindler] Merged SOLR-3733: better organization of javadocs in release [hossman] blurb+link about other possibility of other codecs (merge r1388260) -- [...truncated 16229 lines...] common.init: compile-lucene-core: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml resolve: init: -clover.disable: -clover.setup: clover: compile-core: init: -clover.disable: -clover.setup: clover: common.compile-core: compile-core: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/spatial [echo] Building spatial... download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/spatial [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.spatial... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix.tree... [javadoc] Loading source files for package org.apache.lucene.spatial.query... [javadoc] Loading source files for package org.apache.lucene.spatial.util... [javadoc] Loading source files for package org.apache.lucene.spatial.vector... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [exec] Result: 1 [jar] Building jar: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/spatial/lucene-spatial-4.0-SNAPSHOT-javadoc.jar [echo] Building suggest... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml resolve: common.init: compile-lucene-core: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml resolve: init: -clover.disable: -clover.setup: clover: compile-core: init: -clover.disable: -clover.setup: clover: compile-core: check-lucene-core-javadocs-uptodate: javadocs-lucene-core: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/suggest [echo] Building suggest... download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/suggest [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.search.spell... [javadoc] Loading source files for package org.apache.lucene.search.suggest... [javadoc] Loading source files for package org.apache.lucene.search.suggest.fst... [javadoc] Loading source files for package org.apache.lucene.search.suggest.jaspell... [javadoc] Loading source files for package org.apache.lucene.search.suggest.tst... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [exec] Result: 1 [jar] Building jar: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/suggest/lucene-suggest-4.0-SNAPSHOT-javadoc.jar check-lucene-test-framework-javadocs-uptodate: javadocs-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml resolve: init: check-lucene-core-javadocs-uptodate: javadocs-lucene-core: check-lucene-codecs-javadocs-uptodate: javadocs-lucene-codecs: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/test-framework download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/test-framework [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.codecs.asserting...
Build failed in Jenkins: Lucene-Solr-Robocop #205
See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/205/ -- [...truncated 15983 lines...] common.init: compile-lucene-core: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml resolve: init: -clover.disable: -clover.setup: clover: compile-core: init: -clover.disable: -clover.setup: clover: common.compile-core: compile-core: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/spatial [echo] Building spatial... download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/spatial [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.spatial... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix... [javadoc] Loading source files for package org.apache.lucene.spatial.prefix.tree... [javadoc] Loading source files for package org.apache.lucene.spatial.query... [javadoc] Loading source files for package org.apache.lucene.spatial.util... [javadoc] Loading source files for package org.apache.lucene.spatial.vector... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [exec] Result: 1 [jar] Building jar: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/spatial/lucene-spatial-4.0-SNAPSHOT-javadoc.jar [echo] Building suggest... ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml resolve: common.init: compile-lucene-core: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml resolve: init: -clover.disable: -clover.setup: clover: compile-core: init: -clover.disable: -clover.setup: clover: compile-core: check-lucene-core-javadocs-uptodate: javadocs-lucene-core: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/suggest [echo] Building suggest... download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/suggest [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.search.spell... [javadoc] Loading source files for package org.apache.lucene.search.suggest... [javadoc] Loading source files for package org.apache.lucene.search.suggest.fst... [javadoc] Loading source files for package org.apache.lucene.search.suggest.jaspell... [javadoc] Loading source files for package org.apache.lucene.search.suggest.tst... [javadoc] Constructing Javadoc information... [javadoc] Standard Doclet version 1.7.0_01 [javadoc] Building tree for all the packages and classes... [javadoc] Building index for all the packages and classes... [javadoc] Building index for all classes... [exec] Result: 1 [jar] Building jar: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/suggest/lucene-suggest-4.0-SNAPSHOT-javadoc.jar check-lucene-test-framework-javadocs-uptodate: javadocs-test-framework: ivy-availability-check: ivy-fail: ivy-configure: [ivy:configure] :: loading settings :: file = http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/ivy-settings.xml resolve: init: check-lucene-core-javadocs-uptodate: javadocs-lucene-core: check-lucene-codecs-javadocs-uptodate: javadocs-lucene-codecs: javadocs: [mkdir] Created dir: http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/test-framework download-java6-javadoc-packagelist: [copy] Copying 1 file to http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/ws/lucene/build/docs/test-framework [javadoc] Generating Javadoc [javadoc] Javadoc execution [javadoc] Loading source files for package org.apache.lucene.analysis... [javadoc] Loading source files for package org.apache.lucene.codecs.asserting... [javadoc] Loading source files for package org.apache.lucene.codecs.bloom... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene3x... [javadoc] Loading source files for package org.apache.lucene.codecs.lucene40ords... [javadoc] Loading source files for package org.apache.lucene.codecs.mockintblock... [javadoc] Loading source files for package
Re: [dev]improve the construct in the dev version?
Hello 秋水, I'm afraid there is no general plan for code improvements, but the code is typically improved as people work on it. If you have time/skills, maybe you can contribute your improvements, too, or point out areas that you think are problematic? Otis -- Search Analytics - http://sematext.com/search-analytics/index.html Performance Monitoring - http://sematext.com/spm/index.html On Wed, Sep 19, 2012 at 10:57 PM, 秋水 sdrkyj_luc...@163.com wrote: Hello my comprehending, the ideal construct should use many interfaces, getters and setters. in the 3.6.1 version, there are many suspicious package construct, which must come around with MS dot Net background developer or other programming languages, accompanying much performance considering. is there a good plan or vision on improving it? - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Jenkins build is back to normal : Lucene-Solr-Robocop #206
See http://sierranevada.servebeer.com/job/Lucene-Solr-Robocop/206/changes - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3821) Solr Admin Query form is missing the default search field (df) request parameter
[ https://issues.apache.org/jira/browse/SOLR-3821?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-3821. Resolution: Fixed Fix Version/s: 5.0 Patch was trivial enough that even i could understand it. committed on steffkes behalf since a 4.0 release seems imminent. Committed revision 1388292. Committed revision 1388293. -4x Solr Admin Query form is missing the default search field (df) request parameter -- Key: SOLR-3821 URL: https://issues.apache.org/jira/browse/SOLR-3821 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA Reporter: Jack Krupansky Assignee: Stefan Matheis (steffkes) Fix For: 4.0, 5.0 Attachments: SOLR-3821.patch The default query/search field (df) request parameter is missing from the Solr Admin Query form. This is a common parameter, shared by multiple query parsers. -- 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-3822) Solr Admin Query form does not have hover titles for the edismax request parameters
[ https://issues.apache.org/jira/browse/SOLR-3822?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-3822. Resolution: Fixed Fix Version/s: 5.0 Patch was trivial enough that even i could understand it. committed on steffkes behalf since a 4.0 release seems imminent. Committed revision 1388292. Committed revision 1388293. -4x Solr Admin Query form does not have hover titles for the edismax request parameters --- Key: SOLR-3822 URL: https://issues.apache.org/jira/browse/SOLR-3822 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0-BETA Reporter: Jack Krupansky Assignee: Stefan Matheis (steffkes) Priority: Minor Fix For: 4.0, 5.0 Attachments: SOLR-3822.patch The edismax request parameters on the Solr Admin Query from do not have hover titles, even though the corresponding dismax fields do. Solution: Copy the title attributes from the corresponding dismax parameters. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-4412) Reconsider FunctionValues / ValueSource API
Chris Male created LUCENE-4412: -- Summary: Reconsider FunctionValues / ValueSource API Key: LUCENE-4412 URL: https://issues.apache.org/jira/browse/LUCENE-4412 Project: Lucene - Core Issue Type: Improvement Components: modules/other Reporter: Chris Male Fix For: 5.0 When documenting a lot of these classes today I found myself confused and it isn't the first time with this API. I think we need to step back and reassess what we want from this API, what use cases its designed to meet, and redesign it from the ground up. -- 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-3902) public classes with no javadocs
[
https://issues.apache.org/jira/browse/LUCENE-3902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir resolved LUCENE-3902.
-
Resolution: Fixed
Fix Version/s: 4.0
5.0
public classes with no javadocs
---
Key: LUCENE-3902
URL: https://issues.apache.org/jira/browse/LUCENE-3902
Project: Lucene - Core
Issue Type: Improvement
Components: general/javadocs
Reporter: Robert Muir
Fix For: 5.0, 4.0
Here is a list of public classes with no javadocs.
I think even some simple javadocs can be valuable for all javadocs classes:
* in various summaries, we don't see an empty summary for what the class does
* easier to work with the source in various IDEs that present this stuff on
hover, etc
* better documentation for developers to know what all these classes do.
Maybe we don't have time to fix this for 3.x, but it would be great if anybody
has good knowledge of these classes and could commit any useful stuff to the
javadocs.
Here is the list from Mike's tool on LUCENE-3887
{noformat}
rmuir@beast:~/workspace/lucene-branch3x2/dev-tools/scripts$ python
checkJavaDocs.py ../../lucene/build/docs/api
Check...
../../lucene/build/docs/api/all/org/tartarus/snowball/package-summary.html
missing: Among
missing: TestApp
../../lucene/build/docs/api/all/org/apache/lucene/spatial/tier/package-summary.html
missing: DistanceHandler.Precision
../../lucene/build/docs/api/all/org/apache/lucene/index/package-summary.html
missing: MergePolicy.MergeAbortedException
../../lucene/build/docs/api/all/org/apache/lucene/index/pruning/package-summary.html
missing: CarmelTopKTermPruningPolicy.ByDocComparator
missing: CarmelUniformTermPruningPolicy.ByDocComparator
../../lucene/build/docs/api/all/org/apache/lucene/util/package-summary.html
missing: ByteBlockPool.Allocator
missing: ByteBlockPool.DirectAllocator
missing: ByteBlockPool.DirectTrackingAllocator
missing: BytesRefHash.BytesStartArray
missing: BytesRefHash.DirectBytesStartArray
missing: BytesRefIterator.EmptyBytesRefIterator
missing: DoubleBarrelLRUCache.CloneableKey
missing: English
missing: OpenBitSetDISI
missing: PagedBytes.Reader
missing: StoreClassNameRule
missing: SystemPropertiesInvariantRule
missing: UncaughtExceptionsRule.UncaughtExceptionEntry
missing: UnicodeUtil.UTF16Result
missing: UnicodeUtil.UTF8Result
../../lucene/build/docs/api/all/org/apache/lucene/queryParser/core/nodes/package-summary.html
missing: TextableQueryNode
missing: PathQueryNode.QueryText
missing: PhraseSlopQueryNode
missing: ProximityQueryNode.ProximityType
missing: ModifierQueryNode.Modifier
missing: ParametricQueryNode.CompareOperator
missing: ProximityQueryNode.Type
../../lucene/build/docs/api/all/org/apache/lucene/queryParser/core/parser/package-summary.html
missing: EscapeQuerySyntax.Type
../../lucene/build/docs/api/all/org/apache/lucene/queryParser/standard/builders/package-summary.html
missing: AnyQueryNodeBuilder
../../lucene/build/docs/api/all/org/apache/lucene/queryParser/standard/config/package-summary.html
missing: FuzzyConfig
missing: StandardQueryConfigHandler.ConfigurationKeys
missing: DefaultOperatorAttribute.Operator
missing: StandardQueryConfigHandler.Operator
../../lucene/build/docs/api/all/org/apache/lucene/queryParser/standard/parser/package-summary.html
missing: EscapeQuerySyntaxImpl
missing: StandardSyntaxParser
../../lucene/build/docs/api/all/org/apache/lucene/queryParser/surround/query/package-summary.html
missing: DistanceSubQuery
missing: SimpleTerm.MatchingTermVisitor
missing: AndQuery
missing: BasicQueryFactory
missing: ComposedQuery
missing: DistanceQuery
missing: FieldsQuery
missing: NotQuery
missing: OrQuery
missing: SimpleTerm
missing: SpanNearClauseFactory
missing: SrndPrefixQuery
missing: SrndQuery
missing: SrndTermQuery
missing: SrndTruncQuery
missing: TooManyBasicQueries
../../lucene/build/docs/api/all/org/apache/lucene/store/package-summary.html
missing: FSDirectory.FSIndexOutput
missing: NativePosixUtil
missing: NIOFSDirectory.NIOFSIndexInput
missing: RAMFile
missing: SimpleFSDirectory.SimpleFSIndexInput
missing: SimpleFSDirectory.SimpleFSIndexInput.Descriptor
missing: WindowsDirectory.WindowsIndexInput
missing: MockDirectoryWrapper.Throttling
../../lucene/build/docs/api/all/org/apache/lucene/xmlparser/package-summary.html
missing: FilterBuilder
missing: CorePlusExtensionsParser
missing: DOMUtils
missing: FilterBuilderFactory
missing: QueryBuilderFactory
missing: ParserException
../../lucene/build/docs/api/all/org/apache/lucene/xmlparser/builders/package-summary.html
missing: SpanQueryBuilder
missing:
