Re: PyLucene use JCC shared object by default
Hi Thomas, Our primary motivation was performance and secondary was a pythonic api. Our needs were simpler than the complexity of the whole lucene.facet package. On the Lucene side of things, it looks like we have something similar to CategoryPath (statically 2 deep: /Field/Value) and FacetRequest (only allow searching at root level, optionally only on filtered docs set and fields). Specifically, we implemented an index/cache of all documents and their terms. As far as I know SOLR uses caching of the Lucene index to perform faceting. Our implementation is based on http://lucene.apache.org/solr/api/org/apache/solr/request/UnInvertedField.html and the interface in Python is almost identical. You pass our object an IndexReader and by default all Terms with TermVectors are indexed. You can then selectively retrieve fields. Here's an example of use: http://pastebin.com/Lq3LZKMp. The whole module is ~2000 lines (python interface, c++ implementation, comments). With initial tests, the algorithm is about 100 faster in C++ than when implemented in Python. On Wed, Apr 18, 2012 at 9:31 AM, Thomas Koch k...@orbiteam.de wrote: Hi, sounds like an interesting project – may I ask what you actually implemented and what’s the motivation (e.g. performance?)? I’ve started to experiment with the Facet support in Lucene (actually in PyLucene – ported an example to Python) and found that facetted search support in Lucene looks powerful (though API is still said to be ‘experimental’ and I can’t say anything about performance yet). I’m talking about the org.apache.lucene.facet.* packages – part of the contrib part of Lucene and available as JARs that’s accessible in PyLucene as well. I’m not that familiar with Solr but AFAIK it’s based on Lucene (Java) and should (hopefully) use the same Java code for its facet search support. Of course Solr adds some nice configuration support and web GUI to Lucene, but the ‘core’ search is built on Lucene (to my knowledge). So did you re-implement the Lucene facet search/index code (like TaxonomyReader/Writer, FacetRequest stuff etc.) in C++ or what part of Solr?? Regarding Facet support in PyLucene I can share the samples I’ve ‘ported’ to Python so far. There’s still a patch pending for JavaList (required by facet features) which I come back to later on this list (still some open issues). Hopefully this can be included in the PyLucene 3.6 version … Regards Thomas -- OrbiTeam Software GmbH Co. KG Germany http://www.orbiteam.de Von: Caleb Burns [mailto:ca...@ridersdiscount.com] Gesendet: Dienstag, 17. April 2012 21:16 An: pylucene-dev@lucene.apache.org Betreff: PyLucene use JCC shared object by default Hi, I've finished the process at my organization of re-implementing SOLR's faceting algorithm (in C++). We would like the public at large to have access to the work we've done and plan to do. In order for this to be a real possibility the code needs to be built against and use the same JVM as the PyLucene installation does. The most logical way we feel to have this accomplished is by having PyLucenes' default installation use JCC as a Shared Object. We have yet more plans to extend and provide utilities that work with PyLucene, but this all hinges on having the shared object. The only alternative methodology would require the bundling of our source with the PyLucene project itself as a fork. We are eager to start open sourcing our work, so please let us know what would be the best way to integrate our work. -- Caleb Burns Developer | Riders Discount
Re: [JENKINS] Lucene-Solr-tests-only-trunk-java7 - Build # 2252 - Failure
Reproduces for me: ant test -Dtests.class=*.TestRandomChains -Dtests.method=testRandomChains -Dtests.seed=128642F82A5ED904 -Dtests.multiplier=3 -Dargs=-Dfile.encoding=US-ASCII Dawid On Wed, Apr 18, 2012 at 1:11 AM, Apache Jenkins Server jenk...@builds.apache.org wrote: Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk-java7/2252/ 1 tests failed. REGRESSION: org.apache.lucene.analysis.core.TestRandomChains.testRandomChains Error Message: stage 2: inconsistent startOffset at pos=0: 0 vs 5; token=ಗಚಚ lfxh Stack Trace: java.lang.IllegalStateException: stage 2: inconsistent startOffset at pos=0: 0 vs 5; token=ಗಚಚ lfxh at __randomizedtesting.SeedInfo.seed([128642F82A5ED904:2F676B996D4CC4C4]:0) at org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:128) at org.apache.lucene.analysis.miscellaneous.ASCIIFoldingFilter.incrementToken(ASCIIFoldingFilter.java:71) at org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:78) at org.apache.lucene.analysis.fi.FinnishLightStemFilter.incrementToken(FinnishLightStemFilter.java:48) at org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:78) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:558) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:488) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:430) at org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:856) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:601) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1844) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1000(RandomizedRunner.java:142) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:748) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:823) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:758) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:680) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:613) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:652) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:755) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:142) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:625) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:661) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:672) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:553) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:142) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:499) Build Log (for compile errors): [...truncated 4645 lines...] - 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] [Created] (LUCENE-3996) website System Requirements links to raw page
website System Requirements links to raw page --- Key: LUCENE-3996 URL: https://issues.apache.org/jira/browse/LUCENE-3996 Project: Lucene - Java Issue Type: Bug Reporter: selckin Sorry if this is the wrong place to report this, The System Requirements link on the right @ http://lucene.apache.org/core/documentation.html, link to a raw page without the header menus etc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3364) Logging UI allows multiple selections staying open
[ https://issues.apache.org/jira/browse/SOLR-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3364: Attachment: SOLR-3364.patch Logging UI allows multiple selections staying open -- Key: SOLR-3364 URL: https://issues.apache.org/jira/browse/SOLR-3364 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0 Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Fix For: 4.0 Attachments: SOLR-3364.patch, multiple.png [Jan pointed out|https://issues.apache.org/jira/browse/SOLR-3327?focusedCommentId=13252884page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13252884], that the Logging UI currently allows multiple open selections. Opening a new selection should close all others. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3330) Show changes in plugin statistics across multiple requests
[
https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-3330:
Attachment: SOLR-3330.patch
bq. Right now the UI shows the values from 1, then updates the changes between
23 – the problem is that the values that may have changed between 12 are not
reflected in the UI. (Not a huge deal, but not accurate)
Attached Patch would fix this, i changed the workflow a bit - fetching the
'reference xml' is now done right after loading the initial page.
After a bit playing around with it, i'm not sure, if this is what the user
would expect? image the following: Users loads the page, requests
{{/admin/ping}} or something like this, afterwards hit's the watching changes
button and stop's this action. he'll see at least two changes .. one on the
ping-handler, and one on the mbeans-handler. i would expect, that recording
changes just begin's when i hit the button?
Perhaps it's just a UI-Thing .. maybe we show use some 'loading'-Icon for
Watch Changes instead of the Eye-Icon, to illustrate that we already watch
for changes?
Show changes in plugin statistics across multiple requests
--
Key: SOLR-3330
URL: https://issues.apache.org/jira/browse/SOLR-3330
Project: Solr
Issue Type: New Feature
Components: web gui
Reporter: Ryan McKinley
Fix For: 4.0
Attachments: SOLR-3330-pluggins-diff.patch,
SOLR-3330-pluggins-diff.patch, SOLR-3330-plugins.png,
SOLR-3330-record-changes-ui.patch, SOLR-3330-record-changes-ui.patch,
SOLR-3330-ui-update.patch, SOLR-3330.patch
When debugging configuration and performance, I often:
1. Look at stats values
2. run some queries
3. See how the stats values changed
This is fine, but is often a bit clunky and you have to really know what you
are looking for to see any changes.
It would be great if the 'plugins' page had a button that would make this
easier
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3364) Logging UI allows multiple selections staying open
[ https://issues.apache.org/jira/browse/SOLR-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256266#comment-13256266 ] Ryan McKinley commented on SOLR-3364: - +1 looks good Logging UI allows multiple selections staying open -- Key: SOLR-3364 URL: https://issues.apache.org/jira/browse/SOLR-3364 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0 Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Fix For: 4.0 Attachments: SOLR-3364.patch, multiple.png [Jan pointed out|https://issues.apache.org/jira/browse/SOLR-3327?focusedCommentId=13252884page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13252884], that the Logging UI currently allows multiple open selections. Opening a new selection should close all others. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3330) Show changes in plugin statistics across multiple requests
[ https://issues.apache.org/jira/browse/SOLR-3330?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256269#comment-13256269 ] Ryan McKinley commented on SOLR-3330: - bq. fetching the 'reference xml' is now done right after loading the initial page. eeep. I would expect the changes to be based on when I click the button. I think the way to solve our issue is for the diff request to return the things that did not change as well. I'll make a patch for that and see if we can make that work Show changes in plugin statistics across multiple requests -- Key: SOLR-3330 URL: https://issues.apache.org/jira/browse/SOLR-3330 Project: Solr Issue Type: New Feature Components: web gui Reporter: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3330-pluggins-diff.patch, SOLR-3330-pluggins-diff.patch, SOLR-3330-plugins.png, SOLR-3330-record-changes-ui.patch, SOLR-3330-record-changes-ui.patch, SOLR-3330-ui-update.patch, SOLR-3330.patch When debugging configuration and performance, I often: 1. Look at stats values 2. run some queries 3. See how the stats values changed This is fine, but is often a bit clunky and you have to really know what you are looking for to see any changes. It would be great if the 'plugins' page had a button that would make this easier -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3373) Unknown Characters in MBeanHandler-Output while using diff-feature
Unknown Characters in MBeanHandler-Output while using diff-feature
--
Key: SOLR-3373
URL: https://issues.apache.org/jira/browse/SOLR-3373
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Reporter: Stefan Matheis (steffkes)
Assignee: Ryan McKinley
Fix For: 4.0
i've been watching for changes, in the meantime i requested {{/admin/ping}} for
the first time after starting the instance.
The {{stream.body}}-Property of the {{POST}}-Request to {{/admin/mbeans}}
contains this for the ping-handler:
{code}lst name=org.apache.solr.handler.PingRequestHandler
str name=classorg.apache.solr.handler.PingRequestHandler/str
str name=version4.0.0.2012.04.16.10.12.28/str
str name=descriptionReports application health to a
load-balancer/str
str name=src$URL:
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/PingRequestHandler.java
$/str
lst name=stats
long name=handlerStart1334564025566/long
long name=requests0/long
long name=errors0/long
long name=timeouts0/long
long name=totalTime0/long
float name=avgTimePerRequestNaN/float
float name=avgRequestsPerSecond0.0/float
/lst
/lst{code}
The diff-output contains the following:
{code}/admin/ping:{
class:org.apache.solr.handler.PingRequestHandler,
version:4.0.0.2012.04.16.10.12.28,
description:Reports application health to a load-balancer,
src:$URL:
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/PingRequestHandler.java
$,
stats:{
handlerStart:1334564025566,
requests:Was: 0, Now: 1, Delta: 1,
errors:0,
timeouts:0,
totalTime:Was: 0, Now: 207, Delta: 207,
avgTimePerRequest:Was: NaN, Now: 207.0, Delta: �
}
}{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3364) Logging UI allows multiple selections staying open
[ https://issues.apache.org/jira/browse/SOLR-3364?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) resolved SOLR-3364. - Resolution: Fixed Committed the Fix in r1327405 Logging UI allows multiple selections staying open -- Key: SOLR-3364 URL: https://issues.apache.org/jira/browse/SOLR-3364 Project: Solr Issue Type: Bug Components: web gui Affects Versions: 4.0 Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Fix For: 4.0 Attachments: SOLR-3364.patch, multiple.png [Jan pointed out|https://issues.apache.org/jira/browse/SOLR-3327?focusedCommentId=13252884page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-13252884], that the Logging UI currently allows multiple open selections. Opening a new selection should close all others. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3373) Unknown Characters in MBeanHandler-Output while using diff-feature
[
https://issues.apache.org/jira/browse/SOLR-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256276#comment-13256276
]
Ryan McKinley commented on SOLR-3373:
-
check r1327410
If that fixes things, can you resolve the issue?
Unknown Characters in MBeanHandler-Output while using diff-feature
--
Key: SOLR-3373
URL: https://issues.apache.org/jira/browse/SOLR-3373
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Reporter: Stefan Matheis (steffkes)
Assignee: Ryan McKinley
Fix For: 4.0
i've been watching for changes, in the meantime i requested {{/admin/ping}}
for the first time after starting the instance.
The {{stream.body}}-Property of the {{POST}}-Request to {{/admin/mbeans}}
contains this for the ping-handler:
{code}lst name=org.apache.solr.handler.PingRequestHandler
str name=classorg.apache.solr.handler.PingRequestHandler/str
str name=version4.0.0.2012.04.16.10.12.28/str
str name=descriptionReports application health to a
load-balancer/str
str name=src$URL:
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/PingRequestHandler.java
$/str
lst name=stats
long name=handlerStart1334564025566/long
long name=requests0/long
long name=errors0/long
long name=timeouts0/long
long name=totalTime0/long
float name=avgTimePerRequestNaN/float
float name=avgRequestsPerSecond0.0/float
/lst
/lst{code}
The diff-output contains the following:
{code}/admin/ping:{
class:org.apache.solr.handler.PingRequestHandler,
version:4.0.0.2012.04.16.10.12.28,
description:Reports application health to a load-balancer,
src:$URL:
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/PingRequestHandler.java
$,
stats:{
handlerStart:1334564025566,
requests:Was: 0, Now: 1, Delta: 1,
errors:0,
timeouts:0,
totalTime:Was: 0, Now: 207, Delta: 207,
avgTimePerRequest:Was: NaN, Now: 207.0, Delta: �
}
}{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3373) Unknown Characters in MBeanHandler-Output while using diff-feature
[
https://issues.apache.org/jira/browse/SOLR-3373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) resolved SOLR-3373.
-
Resolution: Fixed
Unknown Characters in MBeanHandler-Output while using diff-feature
--
Key: SOLR-3373
URL: https://issues.apache.org/jira/browse/SOLR-3373
Project: Solr
Issue Type: Bug
Components: web gui
Affects Versions: 4.0
Reporter: Stefan Matheis (steffkes)
Assignee: Ryan McKinley
Fix For: 4.0
i've been watching for changes, in the meantime i requested {{/admin/ping}}
for the first time after starting the instance.
The {{stream.body}}-Property of the {{POST}}-Request to {{/admin/mbeans}}
contains this for the ping-handler:
{code}lst name=org.apache.solr.handler.PingRequestHandler
str name=classorg.apache.solr.handler.PingRequestHandler/str
str name=version4.0.0.2012.04.16.10.12.28/str
str name=descriptionReports application health to a
load-balancer/str
str name=src$URL:
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/PingRequestHandler.java
$/str
lst name=stats
long name=handlerStart1334564025566/long
long name=requests0/long
long name=errors0/long
long name=timeouts0/long
long name=totalTime0/long
float name=avgTimePerRequestNaN/float
float name=avgRequestsPerSecond0.0/float
/lst
/lst{code}
The diff-output contains the following:
{code}/admin/ping:{
class:org.apache.solr.handler.PingRequestHandler,
version:4.0.0.2012.04.16.10.12.28,
description:Reports application health to a load-balancer,
src:$URL:
https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/handler/PingRequestHandler.java
$,
stats:{
handlerStart:1334564025566,
requests:Was: 0, Now: 1, Delta: 1,
errors:0,
timeouts:0,
totalTime:Was: 0, Now: 207, Delta: 207,
avgTimePerRequest:Was: NaN, Now: 207.0, Delta: �
}
}{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3371) Admin UI breaks with a core named 'logging' or 'threads'
[ https://issues.apache.org/jira/browse/SOLR-3371?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Stefan Matheis (steffkes) updated SOLR-3371: Attachment: SOLR-3371.patch bq. It seems like the ~threads and ~logging should be enough to distinguish Hum, yes .. that was the idea :/ Attached Patch changes Handling for global Actions (prefixed with ~) Admin UI breaks with a core named 'logging' or 'threads' Key: SOLR-3371 URL: https://issues.apache.org/jira/browse/SOLR-3371 Project: Solr Issue Type: Bug Components: web gui Reporter: Ryan McKinley Assignee: Stefan Matheis (steffkes) Fix For: 4.0 Attachments: SOLR-3371.patch If you make a core with the name logging or threads the UI gets confused with the logging or threads page. It seems like the ~threads and ~logging should be enough to distinguish -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-1709) Distributed Date and Range Faceting
[ https://issues.apache.org/jira/browse/SOLR-1709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256419#comment-13256419 ] Alejandro Marqués commented on SOLR-1709: - Should the facet.mincount parameter work with distributed date faceting? I have two Solr servers (http://localhost:8090/solr1/ and http://localhost:8090/solr2/) each one with part of the docs from exampledocs If I make the next query: http://localhost:8090/solr1/select/?q=*%3A*version=2.2start=0rows=10indent=onfacet=truefacet.mincount=1facet.date=manufacturedate_dtfacet.date.start=2005-05-01T00:00:00Zfacet.date.end=2006-05-00T00:00:00Zfacet.date.gap=%2B1MONTH The mincount parameter works properly, however, if I add the shards parameter (shards=localhost:8090/solr1,localhost:8090/solr2 or even shards=localhost:8090/solr1): http://localhost:8090/solr1/select/?q=*%3A*version=2.2start=0rows=10indent=onshards=localhost:8090/solr1,localhost:8090/solr2facet=truefacet.mincount=1facet.date=manufacturedate_dtfacet.date.start=2005-05-01T00:00:00Zfacet.date.end=2006-05-00T00:00:00Zfacet.date.gap=%2B1MONTH mincount parameter is being ignored retrieving facets with 0 results. Should the mincount parameter work as in the single search or it is not supported for date facets? Thanks in advance Distributed Date and Range Faceting --- Key: SOLR-1709 URL: https://issues.apache.org/jira/browse/SOLR-1709 Project: Solr Issue Type: Improvement Components: SearchComponents - other Affects Versions: 1.4 Reporter: Peter Sturge Assignee: Simon Willnauer Priority: Minor Fix For: 3.6, 4.0 Attachments: FacetComponent.java, FacetComponent.java, ResponseBuilder.java, SOLR-1709.patch, SOLR-1709_3x.patch, SOLR-1709_distributed_date_faceting_v3x.patch, solr-1.4.0-solr-1709.patch This patch is for adding support for date facets when using distributed searches. Date faceting across multiple machines exposes some time-based issues that anyone interested in this behaviour should be aware of: Any time and/or time-zone differences are not accounted for in the patch (i.e. merged date facets are at a time-of-day, not necessarily at a universal 'instant-in-time', unless all shards are time-synced to the exact same time). The implementation uses the first encountered shard's facet_dates as the basis for subsequent shards' data to be merged in. This means that if subsequent shards' facet_dates are skewed in relation to the first by 1 'gap', these 'earlier' or 'later' facets will not be merged in. There are several reasons for this: * Performance: It's faster to check facet_date lists against a single map's data, rather than against each other, particularly if there are many shards * If 'earlier' and/or 'later' facet_dates are added in, this will make the time range larger than that which was requested (e.g. a request for one hour's worth of facets could bring back 2, 3 or more hours of data) This could be dealt with if timezone and skew information was added, and the dates were normalized. One possibility for adding such support is to [optionally] add 'timezone' and 'now' parameters to the 'facet_dates' map. This would tell requesters what time and TZ the remote server thinks it is, and so multiple shards' time data can be normalized. The patch affects 2 files in the Solr core: org.apache.solr.handler.component.FacetComponent.java org.apache.solr.handler.component.ResponseBuilder.java The main changes are in FacetComponent - ResponseBuilder is just to hold the completed SimpleOrderedMap until the finishStage. One possible enhancement is to perhaps make this an optional parameter, but really, if facet.date parameters are specified, it is assumed they are desired. Comments suggestions welcome. As a favour to ask, if anyone could take my 2 source files and create a PATCH file from it, it would be greatly appreciated, as I'm having a bit of trouble with svn (don't shoot me, but my environment is a Redmond-based os company). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: why the of advance(int target) function of DocIdSetIterator is defined with uncertain?
I found the patch has removed the score(Collector) and
score(Collector,int,int) method. this seems to mean that this scorer is not
possibly used as top-level scorer. Why old implementation has this method?
anywhere use DisjunctionSumScorer as top level scorer?
On Wed, Apr 18, 2012 at 12:18 PM, Li Li fancye...@gmail.com wrote:
thanks. it's great.
On Tue, Apr 17, 2012 at 8:16 PM, Mikhail Khludnev
mkhlud...@griddynamics.com wrote:
Hello,
I can't help with the particular question, but can share some experience.
My task is roughly the same I've found the patch
https://issues.apache.org/jira/browse/LUCENE-2686 is absolutely useful
(with one small addition, I'll post it in comments soon). By using it I
have disjunction summing query with steady subscorers.
Regards
On Tue, Apr 17, 2012 at 2:37 PM, Li Li fancye...@gmail.com wrote:
hi all,
I am now hacking the BooleanScorer2 to let it keep the docID() of
the leaf scorer(mostly possible TermScorer) the same as the top-level
Scorer. Why I want to do this is: When I Collect a doc, I want to know
which term is matched(especially for BooleanClause whose Occur is SHOULD).
we have discussed some solutions, such as adding bit masks in disjunction
scorers. with this method, when we finds a matched doc, we can recursively
find which leaf scorer is matched. But we think it's not very efficient and
not convenient to use(this is my proposal but not agreed by others in our
team). and then we came up with another one: Modifying DisjunctionSumScorer.
we analysed the codes and found that the only Scorers used by
BooleanScorer2 that will make the children scorers' docID() not equal to
parent is an anonymous class inherited from DisjunctionSumScorer. All other
ones including SingleMatchScorer, countingConjunctionSumScorer(anonymous),
dualConjuctionSumScorer, ReqOptSumScorer and ReqExclScorer are fit our need.
The implementation algorithm of DisjunctionSumScorer use a heap to
find the smallest doc. after finding a matched doc, the currentDoc is the
matched doc and all the scorers in the heap will call nextDoc() so all of
the scorers' current docID the nextDoc of currentDoc. if there are N level
DisjunctionSumScorer, the leaf scorer's current doc is the n-th next docId
of the root of the scorer tree.
So we modify the DisjuctionSumScorer and let it behavior as we
expected. And then I wrote some TestCase and it works well. And also I
wrote some random generated TermScorer and compared the nextDoc(),score()
and advance(int) method of original DisjunctionSumScorer and modified one.
nextDoc() and score() and exactly the same. But for advance(int target), we
found some interesting and strange things.
at the beginning, I think if target is less than current docID, it
will just return current docID and do nothing. this assumption let my
algorithm go wrong. Then I read the codes of TermScorer and found each call
of advance(int) of TermScorer will call nextDoc() no matter whether current
docID is larger than target or not.
So I am confused and then read the javadoc of DocIdSetIterator:
- javadoc of DocIdSetIterator.advance(int
target)-
int org.apache.lucene.search.DocIdSetIterator.advance(int target) throws
IOException
Advances to the first beyond (see NOTE below) the current whose document
number is greater than or equal
to target. Returns the current document number or NO_MORE_DOCS if there
are no more docs in the set.
Behaves as if written:
int advance(int target) {
int doc;
while ((doc = nextDoc()) target) {
}
return doc;
}
Some implementations are considerably more efficient than that.
NOTE: when target current implementations may opt not to advance
beyond their current docID().
NOTE: this method may be called with NO_MORE_DOCS for efficiency by some
Scorers. If your
implementation cannot efficiently determine that it should exhaust, it
is recommended that you check for
that value in each call to this method.
NOTE: after the iterator has exhausted you should not call this method,
as it may result in unpredicted
behavior.
--
Then I modified my algorithm again and found that
DisjunctionSumScorer.advance(int target) has some strange behavior. most of
the cases, it will return currentDoc if target currentDoc. but in some
boundary condition, it will not.
it's not a bug but let me sad. I thought my algorithm has some bug
because it's advance method is not exactly the same as original
DisjunctionSumScorer's.
codes of DisjunctionSumScorer---
@Override
public int advance(int target) throws IOException {
if (scorerDocQueue.size() minimumNrMatchers) {
return currentDoc = NO_MORE_DOCS;
}
if (target = currentDoc) {
return currentDoc;
}
---
for most case if (target = currentDoc) it will return currentDoc;
but if previous advance will make
[jira] [Commented] (LUCENE-3996) website System Requirements links to raw page
[ https://issues.apache.org/jira/browse/LUCENE-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256445#comment-13256445 ] Robert Muir commented on LUCENE-3996: - its in markdown (.txt), not .html on the webserver. thanks for pointing this out. website System Requirements links to raw page --- Key: LUCENE-3996 URL: https://issues.apache.org/jira/browse/LUCENE-3996 Project: Lucene - Java Issue Type: Bug Reporter: selckin Sorry if this is the wrong place to report this, The System Requirements link on the right @ http://lucene.apache.org/core/documentation.html, link to a raw page without the header menus etc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3996) website System Requirements links to raw page
[ https://issues.apache.org/jira/browse/LUCENE-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256451#comment-13256451 ] Robert Muir commented on LUCENE-3996: - I committed a fix (r1327445), waiting on the cms to come back up before getting it out there though (http://monitoring.apache.org/status/). website System Requirements links to raw page --- Key: LUCENE-3996 URL: https://issues.apache.org/jira/browse/LUCENE-3996 Project: Lucene - Java Issue Type: Bug Reporter: selckin Sorry if this is the wrong place to report this, The System Requirements link on the right @ http://lucene.apache.org/core/documentation.html, link to a raw page without the header menus etc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Problem running all of a module's tests under IntelliJ: Wrong test finished.
I think I know what the problem is and I'm working on a fix. This may require you to set a property strictJunitCompatibilityIsStupid though... I'm not really keen on making what I consider flaws in JUnit a default behavior :) Dawid On Wed, Apr 18, 2012 at 12:05 AM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: Thanks Steve, I'll be bulk-fixing all the discovered issues tomorrow. I'll let you know if I figure out what's causing this. Dawid On Wed, Apr 18, 2012 at 12:00 AM, Steven A Rowe sar...@syr.edu wrote: Dawid, I have included in the IntelliJ IDEA configuration for Lucene/Solr a set of run configurations, one per module, that runs all tests in each module. After you have run ant idea at the top level, then opened the project in IntelliJ IDEA, then set up the JDK to use (the menu path to set up the JDK is printed to the terminal after you run ant idea) you should be able to see something similar to this: http://postimage.org/image/ivi5srd5v To the left of the triangular green arrow icon (which means: run the selected run configuration), there is a dropdown menu for run configurations. In the above-linked image, I've left-clicked on this dropdown, and the mouse is hovering over Module analyzers-common - this is one of the modules that exhibits the test running problem. Left-click on Module analyzers-common to set the active run configuration. After you do this, the run configuration dropdown will change to display this label. Then you can start the tests associated with this by clicking on the green triangular button to the right of the run configuration dropdown. When IntelliJ runs tests, it will first make the associated module and its dependent modules, then show a JUnit pane at the bottom of the window, with a tree of test suites and their tests on the left, and console output on the right. Let me know if you need more info. Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Tuesday, April 17, 2012 5:26 PM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. Steven can you send me a screenshot or something showing where I should click to get this failure? :) Dawid On Tue, Apr 17, 2012 at 6:04 PM, Steven A Rowe sar...@syr.edu wrote: Hi Dawid :) Do you use IntelliJ? There appears to be some form of bad interaction between the new RandomizedTesting library additions and IntelliJ's test runner. When I try to run all of an IntelliJ module's tests under IntelliJ, e.g. analyzers-common or lucene (including core and test-framework), not all tests run; those that don't run are reported as not started. The external test process reports Wrong test finished. (???) and then returns exit code -1. This behavior is relatively new - I don't think the modules/*-lucene/ move is the culprit (the IntelliJ lucene+test-framework module didn't move and it has this issue). Here's the output from running all analyzers-common tests: -- C:\Program Files\Java\jdk1.6.0_21\bin\java -ea -DtempDir=temp -Didea.launcher.port=7541 -Didea.launcher.bin.path=C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\bin -Dfile.encoding=UTF-8 -classpath C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\lib\idea_rt.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\plugins\junit\lib\junit-rt.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\alt-rt.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\jce.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\resources.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\rt.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\ext\sunjce_provider.jar;C:\svn\lucene\d ev\trunk\lucene\build\analysis\analyzers-common\classes\test;C:\svn\lu cene\dev\trunk\lucene\build\analysis\analyzers-common\classes\java;C:\ svn\lucene\dev\trunk\lucene\test-framework\lib\junit-4.10.jar;C:\svn\l ucene\dev\trunk\lucene\test-framework\lib\randomizedtesting-runner-1.2 .0.jar;C:\svn\lucene\dev\trunk\lucene\build\lucene-idea\classes\test;C :\svn\lucene\dev\trunk\lucene\build\lucene-idea\classes\java;C:\svn\lu cene\dev\trunk\lucene\test-framework\lib\ant-1.7.1.jar;C:\svn\lucene\d ev\trunk\lucene\test-framework\lib\ant-junit-1.7.1.jar com.intellij.rt.execution.application.AppMain com.intellij.rt.execution.junit.JUnitStarter -ideVersion5 @C:\Users\sarowe\AppData\Local\Temp\idea_junit3377604973713774012.tmp -socket53790 Test '.default
[jira] [Commented] (LUCENE-2686) DisjunctionSumScorer should not call .score on sub scorers until consumer calls .score
[ https://issues.apache.org/jira/browse/LUCENE-2686?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256462#comment-13256462 ] LiLi commented on LUCENE-2686: -- I test the speed of this one with old one. I used randomly generated term scorers and just call nextDoc() until NO_MORE_DOCS the new one is much slower than old one(I don't score the doc) DisjunctionSumScorer should not call .score on sub scorers until consumer calls .score -- Key: LUCENE-2686 URL: https://issues.apache.org/jira/browse/LUCENE-2686 Project: Lucene - Java Issue Type: Bug Components: core/search Reporter: Michael McCandless Assignee: Michael McCandless Fix For: 4.0 Attachments: LUCENE-2686.patch, LUCENE-2686.patch, Test2LUCENE2590.java Spinoff from java-user thread question about Scorer.freq() from Koji... BooleanScorer2 uses DisjunctionSumScorer to score only-SHOULD-clause boolean queries. But, this scorer does too much work for collectors that never call .score, because it scores while it's matching. It should only call .score on the subs when the caller calls its .score. This also has the side effect of messing up advanced collectors that gather the freq() of the subs (using LUCENE-2590). -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Problem running all of a module's tests under IntelliJ: Wrong test finished.
Cool, thanks! -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Wednesday, April 18, 2012 7:44 AM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. I think I know what the problem is and I'm working on a fix. This may require you to set a property strictJunitCompatibilityIsStupid though... I'm not really keen on making what I consider flaws in JUnit a default behavior :) Dawid On Wed, Apr 18, 2012 at 12:05 AM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: Thanks Steve, I'll be bulk-fixing all the discovered issues tomorrow. I'll let you know if I figure out what's causing this. Dawid On Wed, Apr 18, 2012 at 12:00 AM, Steven A Rowe sar...@syr.edu wrote: Dawid, I have included in the IntelliJ IDEA configuration for Lucene/Solr a set of run configurations, one per module, that runs all tests in each module. After you have run ant idea at the top level, then opened the project in IntelliJ IDEA, then set up the JDK to use (the menu path to set up the JDK is printed to the terminal after you run ant idea) you should be able to see something similar to this: http://postimage.org/image/ivi5srd5v To the left of the triangular green arrow icon (which means: run the selected run configuration), there is a dropdown menu for run configurations. In the above-linked image, I've left-clicked on this dropdown, and the mouse is hovering over Module analyzers-common - this is one of the modules that exhibits the test running problem. Left-click on Module analyzers-common to set the active run configuration. After you do this, the run configuration dropdown will change to display this label. Then you can start the tests associated with this by clicking on the green triangular button to the right of the run configuration dropdown. When IntelliJ runs tests, it will first make the associated module and its dependent modules, then show a JUnit pane at the bottom of the window, with a tree of test suites and their tests on the left, and console output on the right. Let me know if you need more info. Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Tuesday, April 17, 2012 5:26 PM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. Steven can you send me a screenshot or something showing where I should click to get this failure? :) Dawid On Tue, Apr 17, 2012 at 6:04 PM, Steven A Rowe sar...@syr.edu wrote: Hi Dawid :) Do you use IntelliJ? There appears to be some form of bad interaction between the new RandomizedTesting library additions and IntelliJ's test runner. When I try to run all of an IntelliJ module's tests under IntelliJ, e.g. analyzers-common or lucene (including core and test-framework), not all tests run; those that don't run are reported as not started. The external test process reports Wrong test finished. (???) and then returns exit code -1. This behavior is relatively new - I don't think the modules/*-lucene/ move is the culprit (the IntelliJ lucene+test-framework module didn't move and it has this issue). Here's the output from running all analyzers-common tests: -- C:\Program Files\Java\jdk1.6.0_21\bin\java -ea -DtempDir=temp -Didea.launcher.port=7541 -Didea.launcher.bin.path=C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\bin -Dfile.encoding=UTF-8 -classpath C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\lib\idea_rt.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\plugins\junit\lib\junit-rt.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\alt-rt.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\jce.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\resources.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\rt.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\ext\sunjce_provider.jar;C:\svn\lucene \d ev\trunk\lucene\build\analysis\analyzers-common\classes\test;C:\svn\ lu cene\dev\trunk\lucene\build\analysis\analyzers-common\classes\java;C :\ svn\lucene\dev\trunk\lucene\test-framework\lib\junit-4.10.jar;C:\svn \l ucene\dev\trunk\lucene\test-framework\lib\randomizedtesting-runner-1 .2 .0.jar;C:\svn\lucene\dev\trunk\lucene\build\lucene-idea\classes\test ;C :\svn\lucene\dev\trunk\lucene\build\lucene-idea\classes\java;C:\svn\ lu
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 13245 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13245/ 1 tests failed. REGRESSION: org.apache.lucene.analysis.core.TestRandomChains.testRandomChains Error Message: last stage: inconsistent startOffset at pos=0: 0 vs 5; token=gzzu )*)*- Stack Trace: java.lang.IllegalStateException: last stage: inconsistent startOffset at pos=0: 0 vs 5; token=gzzu )*)*- at __randomizedtesting.SeedInfo.seed([CAECCFB7E3756835:F70DE6D6A46775F5]:0) at org.apache.lucene.analysis.ValidatingTokenFilter.incrementToken(ValidatingTokenFilter.java:128) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkAnalysisConsistency(BaseTokenStreamTestCase.java:558) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:488) at org.apache.lucene.analysis.BaseTokenStreamTestCase.checkRandomData(BaseTokenStreamTestCase.java:430) at org.apache.lucene.analysis.core.TestRandomChains.testRandomChains(TestRandomChains.java:856) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:616) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1844) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$1000(RandomizedRunner.java:142) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:748) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:809) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:823) at org.apache.lucene.util.LuceneTestCase$SubclassSetupTeardownRule$1.evaluate(LuceneTestCase.java:758) at org.apache.lucene.util.LuceneTestCase$InternalSetupTeardownRule$1.evaluate(LuceneTestCase.java:680) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at org.apache.lucene.util.LuceneTestCase$TestResultInterceptorRule$1.evaluate(LuceneTestCase.java:613) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.LuceneTestCase$SaveThreadAndTestNameRule$1.evaluate(LuceneTestCase.java:652) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:755) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:142) at com.carrotsearch.randomizedtesting.RandomizedRunner$3$1.run(RandomizedRunner.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:625) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:661) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:672) at org.apache.lucene.util.UncaughtExceptionsRule$1.evaluate(UncaughtExceptionsRule.java:75) at org.apache.lucene.util.StoreClassNameRule$1.evaluate(StoreClassNameRule.java:38) at org.apache.lucene.util.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:69) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSuite(RandomizedRunner.java:553) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$400(RandomizedRunner.java:142) at com.carrotsearch.randomizedtesting.RandomizedRunner$2.run(RandomizedRunner.java:499) Build Log (for compile errors): [...truncated 3882 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[ https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256505#comment-13256505 ] Yonik Seeley commented on SOLR-3362: I assume you're not using the jetty bundled with Solr? If not, let's check that first by running exampledocs/test_utf8.sh FacetComponent throws NPE when doing distributed query -- Key: SOLR-3362 URL: https://issues.apache.org/jira/browse/SOLR-3362 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: RHEL lucene svn revision 1308309 Reporter: Jamie Johnson When executing a query against a field in my index I am getting the following exception The query I am executing is as follows: http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization debugging the FacetComponent line 489 sfc is null SEVERE: java.lang.NullPointerException at org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489) at org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (LUCENE-3994) some nightly tests take hours
[ https://issues.apache.org/jira/browse/LUCENE-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir reopened LUCENE-3994: - This still occurs. I profiled the slow tests and found its because of the huge 1GB linedocs file. The problem is opening this 1GB zipped file and seeking to a random place (which is what LineDocs does), is really costly. so all the time is spent in GZIPInputStream.inflateBytes! I will temporary disable the huge file for nightly builds. some nightly tests take hours - Key: LUCENE-3994 URL: https://issues.apache.org/jira/browse/LUCENE-3994 Project: Lucene - Java Issue Type: Bug Components: general/build Affects Versions: 4.0 Reporter: Robert Muir Fix For: 4.0 Attachments: LUCENE-3994.patch The nightly builds are taking 4-7 hours. This is caused by a few bad apples (can be seen https://builds.apache.org/job/Lucene-trunk/1896/testReport/). The top 5 are (all in analysis): * TestSynonymMapFilter: 1 hr 54 min * TestRandomChains: 1 hr 22 min * TestRemoveDuplicatesTokenFilter: 32 min * TestMappingCharFilter: 28 min * TestWordDelimiterFilter: 22 min so thats 4.5 hours right there for that run -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[ https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256541#comment-13256541 ] Jamie Johnson commented on SOLR-3362: - I am using the jetty bundled with Solr, absolutely no changes at all in that regard. What I am having difficulty doing is duplicating this issue on a very small set of data, I can only duplicate with the actual data right now. If I run a very simple test and add some of the extended ASCII characters it appears in the facets properly, but with the actual data I am having issues, not sure why. FacetComponent throws NPE when doing distributed query -- Key: SOLR-3362 URL: https://issues.apache.org/jira/browse/SOLR-3362 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: RHEL lucene svn revision 1308309 Reporter: Jamie Johnson When executing a query against a field in my index I am getting the following exception The query I am executing is as follows: http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization debugging the FacetComponent line 489 sfc is null SEVERE: java.lang.NullPointerException at org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489) at org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3994) some nightly tests take hours
[
https://issues.apache.org/jira/browse/LUCENE-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256548#comment-13256548
]
Robert Muir commented on LUCENE-3994:
-
I'll leave the issue open, until we get the next nightly done, but this was
pretty difficult to debug:
Jenkins test time is now a total lie! I think its the clover time?
Have a look at last nights build:
https://builds.apache.org/job/Lucene-Trunk/1898/
The entire build took 5 hours, yet it says tests took only 47 minutes:
https://builds.apache.org/job/Lucene-Trunk/1898/testReport/
Looking at the console you can see this is not the case:
Actual tests:
{noformat}
BUILD SUCCESSFUL
Total time: 225 minutes 56 seconds
{noformat}
Clovered tests:
{noformat}
BUILD SUCCESSFUL
Total time: 54 minutes 31 seconds
{noformat}
Its possible i screwed this up with the nightly build changes from LUCENE-3965.
I'll investigate.
some nightly tests take hours
-
Key: LUCENE-3994
URL: https://issues.apache.org/jira/browse/LUCENE-3994
Project: Lucene - Java
Issue Type: Bug
Components: general/build
Affects Versions: 4.0
Reporter: Robert Muir
Fix For: 4.0
Attachments: LUCENE-3994.patch
The nightly builds are taking 4-7 hours.
This is caused by a few bad apples (can be seen
https://builds.apache.org/job/Lucene-trunk/1896/testReport/).
The top 5 are (all in analysis):
* TestSynonymMapFilter: 1 hr 54 min
* TestRandomChains: 1 hr 22 min
* TestRemoveDuplicatesTokenFilter: 32 min
* TestMappingCharFilter: 28 min
* TestWordDelimiterFilter: 22 min
so thats 4.5 hours right there for that run
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
AW: PyLucene use JCC shared object by default
Hi, sounds like an interesting project – may I ask what you actually implemented and what’s the motivation (e.g. performance?)? I’ve started to experiment with the Facet support in Lucene (actually in PyLucene – ported an example to Python) and found that facetted search support in Lucene looks powerful (though API is still said to be ‘experimental’ and I can’t say anything about performance yet). I’m talking about the org.apache.lucene.facet.* packages – part of the contrib part of Lucene and available as JARs that’s accessible in PyLucene as well. I’m not that familiar with Solr but AFAIK it’s based on Lucene (Java) and should (hopefully) use the same Java code for its facet search support. Of course Solr adds some nice configuration support and web GUI to Lucene, but the ‘core’ search is built on Lucene (to my knowledge). So did you re-implement the Lucene facet search/index code (like TaxonomyReader/Writer, FacetRequest stuff etc.) in C++ or what part of Solr?? Regarding Facet support in PyLucene I can share the samples I’ve ‘ported’ to Python so far. There’s still a patch pending for JavaList (required by facet features) which I come back to later on this list (still some open issues). Hopefully this can be included in the PyLucene 3.6 version … Regards Thomas -- OrbiTeam Software GmbH Co. KG Germany http://www.orbiteam.de Von: Caleb Burns [mailto:ca...@ridersdiscount.com] Gesendet: Dienstag, 17. April 2012 21:16 An: pylucene-...@lucene.apache.org Betreff: PyLucene use JCC shared object by default Hi, I've finished the process at my organization of re-implementing SOLR's faceting algorithm (in C++). We would like the public at large to have access to the work we've done and plan to do. In order for this to be a real possibility the code needs to be built against and use the same JVM as the PyLucene installation does. The most logical way we feel to have this accomplished is by having PyLucenes' default installation use JCC as a Shared Object. We have yet more plans to extend and provide utilities that work with PyLucene, but this all hinges on having the shared object. The only alternative methodology would require the bundling of our source with the PyLucene project itself as a fork. We are eager to start open sourcing our work, so please let us know what would be the best way to integrate our work. -- Caleb Burns Developer | Riders Discount 866.931.6644 x851 | www.RidersDiscount.com Deal of the Day
[jira] [Commented] (LUCENE-3994) some nightly tests take hours
[ https://issues.apache.org/jira/browse/LUCENE-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256550#comment-13256550 ] Dawid Weiss commented on LUCENE-3994: - I've fixed that per-suite constant suite randomization already in github but I'll need some time to push to maven central, etc. some nightly tests take hours - Key: LUCENE-3994 URL: https://issues.apache.org/jira/browse/LUCENE-3994 Project: Lucene - Java Issue Type: Bug Components: general/build Affects Versions: 4.0 Reporter: Robert Muir Fix For: 4.0 Attachments: LUCENE-3994.patch The nightly builds are taking 4-7 hours. This is caused by a few bad apples (can be seen https://builds.apache.org/job/Lucene-trunk/1896/testReport/). The top 5 are (all in analysis): * TestSynonymMapFilter: 1 hr 54 min * TestRandomChains: 1 hr 22 min * TestRemoveDuplicatesTokenFilter: 32 min * TestMappingCharFilter: 28 min * TestWordDelimiterFilter: 22 min so thats 4.5 hours right there for that run -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3994) some nightly tests take hours
[ https://issues.apache.org/jira/browse/LUCENE-3994?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256556#comment-13256556 ] Robert Muir commented on LUCENE-3994: - Thanks Dawid, I am looking forward to that! some nightly tests take hours - Key: LUCENE-3994 URL: https://issues.apache.org/jira/browse/LUCENE-3994 Project: Lucene - Java Issue Type: Bug Components: general/build Affects Versions: 4.0 Reporter: Robert Muir Fix For: 4.0 Attachments: LUCENE-3994.patch The nightly builds are taking 4-7 hours. This is caused by a few bad apples (can be seen https://builds.apache.org/job/Lucene-trunk/1896/testReport/). The top 5 are (all in analysis): * TestSynonymMapFilter: 1 hr 54 min * TestRandomChains: 1 hr 22 min * TestRemoveDuplicatesTokenFilter: 32 min * TestMappingCharFilter: 28 min * TestWordDelimiterFilter: 22 min so thats 4.5 hours right there for that run -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[
https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256565#comment-13256565
]
Yonik Seeley commented on SOLR-3362:
OK, then the next most likely possibility would seem to be the client sending
the sub-request.
I just managed to reproduce this problem with this URL:
http://localhost:8983/solr/select?wt=pythonindent=trueq=*:*facet=truefacet.query={!term%20f=id}wx%C2%A0yzshards=localhost:8983/solr
FacetComponent throws NPE when doing distributed query
--
Key: SOLR-3362
URL: https://issues.apache.org/jira/browse/SOLR-3362
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: RHEL
lucene svn revision 1308309
Reporter: Jamie Johnson
When executing a query against a field in my index I am getting the following
exception
The query I am executing is as follows:
http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization
debugging the FacetComponent line 489 sfc is null
SEVERE: java.lang.NullPointerException
at
org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489)
at
org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:351)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634)
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534)
at java.lang.Thread.run(Thread.java:662)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3997) join module should not depend on grouping module
join module should not depend on grouping module Key: LUCENE-3997 URL: https://issues.apache.org/jira/browse/LUCENE-3997 Project: Lucene - Java Issue Type: Task Affects Versions: 4.0 Reporter: Robert Muir Fix For: 4.0 I think TopGroups/GroupDocs should simply be in core? Both grouping and join modules use these trivial classes, but join depends on grouping just for them. I think its better that we try to minimize these inter-module dependencies. Of course, another option is to combine grouping and join into one module, but last time i brought that up nobody could agree on a name. Anyway I think the change is pretty clean: its similar to having basic stuff like Analyzer.java in core, so other things can work with Analyzer without depending on any specific implementing modules. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[
https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256570#comment-13256570
]
Yonik Seeley commented on SOLR-3362:
Oh yuck... I just used netcat to listen on port 8985 and changed the shards
parameter to that to see just what was being sent.
What a waste of space! And that is where the charset is getting hacked...
{code}
/opt/code/lusolr/solr/example/exampledocs$ nc -l 8985
POST /solr/select HTTP/1.1
User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
Content-Charset: UTF-8
Accept-Charset: UTF-8
Content-Length: 1217
Content-Type: multipart/form-data; boundary=eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Host: localhost:8985
Connection: Keep-Alive
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=rows
10
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=facet
true
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=facet.query
{!term f=id}wx?yz
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=q
*:*
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=start
0
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=fsv
true
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=fl
id,score
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=distrib
false
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=isShard
true
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=shard.url
localhost:8985/solr
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=NOW
1334757315277
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=wt
javabin
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=version
2
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3--
{code}
FacetComponent throws NPE when doing distributed query
--
Key: SOLR-3362
URL: https://issues.apache.org/jira/browse/SOLR-3362
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: RHEL
lucene svn revision 1308309
Reporter: Jamie Johnson
When executing a query against a field in my index I am getting the following
exception
The query I am executing is as follows:
http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization
debugging the FacetComponent line 489 sfc is null
SEVERE: java.lang.NullPointerException
at
org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489)
at
org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:351)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at
[jira] [Updated] (LUCENE-3997) join module should not depend on grouping module
[
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-3997:
Attachment: LUCENE-3997.patch
Patch, after:
{noformat}
svn mv
lucene/grouping/src/java/org/apache/lucene/search/grouping/TopGroups.java
lucene/core/src/java/org/apache/lucene/search
svn mv
lucene/grouping/src/java/org/apache/lucene/search/grouping/GroupDocs.java
lucene/core/src/java/org/apache/lucene/search
{noformat}
join module should not depend on grouping module
Key: LUCENE-3997
URL: https://issues.apache.org/jira/browse/LUCENE-3997
Project: Lucene - Java
Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
Fix For: 4.0
Attachments: LUCENE-3997.patch
I think TopGroups/GroupDocs should simply be in core?
Both grouping and join modules use these trivial classes, but join depends on
grouping just for them.
I think its better that we try to minimize these inter-module dependencies.
Of course, another option is to combine grouping and join into one module, but
last time i brought that up nobody could agree on a name.
Anyway I think the change is pretty clean: its similar to having basic stuff
like Analyzer.java in core,
so other things can work with Analyzer without depending on any specific
implementing modules.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[
https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256571#comment-13256571
]
Yonik Seeley commented on SOLR-3362:
Oh yuck... I just used netcat to listen on port 8985 and changed the shards
parameter to that to see just what was being sent.
What a waste of space! And that is where the charset is getting hacked...
{code}
/opt/code/lusolr/solr/example/exampledocs$ nc -l 8985
POST /solr/select HTTP/1.1
User-Agent: Solr[org.apache.solr.client.solrj.impl.HttpSolrServer] 1.0
Content-Charset: UTF-8
Accept-Charset: UTF-8
Content-Length: 1217
Content-Type: multipart/form-data; boundary=eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Host: localhost:8985
Connection: Keep-Alive
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=rows
10
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=facet
true
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=facet.query
{!term f=id}wx?yz
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=q
*:*
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=start
0
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=fsv
true
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=fl
id,score
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=distrib
false
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=isShard
true
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=shard.url
localhost:8985/solr
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=NOW
1334757315277
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=wt
javabin
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3
Content-Disposition: form-data; name=version
2
--eADQ-PDh-HqmlsJi5PyvlmPclUWpz3--
{code}
FacetComponent throws NPE when doing distributed query
--
Key: SOLR-3362
URL: https://issues.apache.org/jira/browse/SOLR-3362
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: RHEL
lucene svn revision 1308309
Reporter: Jamie Johnson
When executing a query against a field in my index I am getting the following
exception
The query I am executing is as follows:
http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization
debugging the FacetComponent line 489 sfc is null
SEVERE: java.lang.NullPointerException
at
org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489)
at
org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111)
at org.eclipse.jetty.server.Server.handle(Server.java:351)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890)
at
[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module
[ https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256577#comment-13256577 ] Robert Muir commented on LUCENE-3997: - Sorry for the duplicate upload... jira was going nutso on me join module should not depend on grouping module Key: LUCENE-3997 URL: https://issues.apache.org/jira/browse/LUCENE-3997 Project: Lucene - Java Issue Type: Task Affects Versions: 4.0 Reporter: Robert Muir Fix For: 4.0 Attachments: LUCENE-3997.patch, LUCENE-3997.patch I think TopGroups/GroupDocs should simply be in core? Both grouping and join modules use these trivial classes, but join depends on grouping just for them. I think its better that we try to minimize these inter-module dependencies. Of course, another option is to combine grouping and join into one module, but last time i brought that up nobody could agree on a name. Anyway I think the change is pretty clean: its similar to having basic stuff like Analyzer.java in core, so other things can work with Analyzer without depending on any specific implementing modules. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3997) join module should not depend on grouping module
[
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-3997:
Attachment: LUCENE-3997.patch
Patch, after:
{noformat}
svn mv
lucene/grouping/src/java/org/apache/lucene/search/grouping/TopGroups.java
lucene/core/src/java/org/apache/lucene/search
svn mv
lucene/grouping/src/java/org/apache/lucene/search/grouping/GroupDocs.java
lucene/core/src/java/org/apache/lucene/search
{noformat}
join module should not depend on grouping module
Key: LUCENE-3997
URL: https://issues.apache.org/jira/browse/LUCENE-3997
Project: Lucene - Java
Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
Fix For: 4.0
Attachments: LUCENE-3997.patch, LUCENE-3997.patch
I think TopGroups/GroupDocs should simply be in core?
Both grouping and join modules use these trivial classes, but join depends on
grouping just for them.
I think its better that we try to minimize these inter-module dependencies.
Of course, another option is to combine grouping and join into one module, but
last time i brought that up nobody could agree on a name.
Anyway I think the change is pretty clean: its similar to having basic stuff
like Analyzer.java in core,
so other things can work with Analyzer without depending on any specific
implementing modules.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[ https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256592#comment-13256592 ] Yonik Seeley commented on SOLR-3362: OK, I just verified that this is not a problem with older trunk builds, so this was an issue introduced by the new http client 4 (upgraded on 3/29). Before that, we get a normal looking single-part post with correct encoding. FacetComponent throws NPE when doing distributed query -- Key: SOLR-3362 URL: https://issues.apache.org/jira/browse/SOLR-3362 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: RHEL lucene svn revision 1308309 Reporter: Jamie Johnson When executing a query against a field in my index I am getting the following exception The query I am executing is as follows: http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization debugging the FacetComponent line 489 sfc is null SEVERE: java.lang.NullPointerException at org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489) at org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-2020) HttpComponentsSolrServer
[ https://issues.apache.org/jira/browse/SOLR-2020?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley reopened SOLR-2020: reopening - it looks like we have a charset encoding issue. See SOLR-3362 HttpComponentsSolrServer Key: SOLR-2020 URL: https://issues.apache.org/jira/browse/SOLR-2020 Project: Solr Issue Type: New Feature Components: clients - java Affects Versions: 1.4.1 Environment: Any Reporter: Chantal Ackermann Assignee: Sami Siren Priority: Minor Fix For: 3.6, 4.0 Attachments: HttpComponentsSolrServer.java, HttpComponentsSolrServerTest.java, SOLR-2020-3x.patch, SOLR-2020-HttpSolrServer.patch, SOLR-2020.patch, SOLR-2020.patch, SOLR-2020.patch, SOLR-2020.patch Implementation of SolrServer that uses the Apache Http Components framework. Http Components (http://hc.apache.org/) is the successor of Commons HttpClient and thus HttpComponentsSolrServer would be a successor of CommonsHttpSolrServer, in the future. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[ https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256598#comment-13256598 ] Jamie Johnson commented on SOLR-3362: - I don't claim to understand what specifically the issue is but I am glad that we were able to duplicate it. We had never seen this issue on previous builds so it makes sense that this issue was introduced as part of that switch. Again I really appreciate you digging into this. FacetComponent throws NPE when doing distributed query -- Key: SOLR-3362 URL: https://issues.apache.org/jira/browse/SOLR-3362 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: RHEL lucene svn revision 1308309 Reporter: Jamie Johnson When executing a query against a field in my index I am getting the following exception The query I am executing is as follows: http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization debugging the FacetComponent line 489 sfc is null SEVERE: java.lang.NullPointerException at org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489) at org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-3998) facet module should have no dependencies, consolidate examples into demo/
facet module should have no dependencies, consolidate examples into demo/ - Key: LUCENE-3998 URL: https://issues.apache.org/jira/browse/LUCENE-3998 Project: Lucene - Java Issue Type: Task Components: modules/facet Affects Versions: 4.0 Reporter: Robert Muir currently facets depends on analyzers-common, but this is unnecessary. additionally it has a nice examples/ package (even with javadocs! are they actually seen anywhere?!), as well as tests for those examples. I think instead it would be better if facet/ had no dependencies, and if examples+examples tests were in demo/. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #459: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/459/ No tests ran. Build Log (for compile errors): [...truncated 7988 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3998) facet module should have no dependencies, consolidate examples into demo/
[
https://issues.apache.org/jira/browse/LUCENE-3998?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-3998:
Attachment: LUCENE-3998.patch
here's an initial patch (all tests pass), but there are things i don't like:
see the comments in the script (which you must run first, before applying the
patch):
{noformat}
mkdir -p lucene/demo/src/java/org/apache/lucene/facet
svn add lucene/demo/src/java/org/apache/lucene/facet
svn mv lucene/facet/src/examples/org/apache/lucene/facet/example
lucene/demo/src/java/org/apache/lucene/facet
svn delete lucene/facet/src/examples
mkdir -p lucene/demo/src/test/org/apache/lucene/facet
svn add lucene/demo/src/test/org/apache/lucene/facet
svn mv lucene/facet/src/test/org/apache/lucene/facet/example
lucene/demo/src/test/org/apache/lucene/facet
# move to test-framework
svn move lucene/facet/src/test/org/apache/lucene/util/SlowRAMDirectory.java
lucene/test-framework/src/java/org/apache/lucene/util
# nocommit: can we improve this? some facet tests testing real functionality,
but
# using example stuff... if the tests arent actually testing the example they
should stay in facet/
# and we won't need to bogusly code-dup the FacetTestUtils?
svn copy lucene/facet/src/test/org/apache/lucene/facet/FacetTestUtils.java
lucene/demo/src/test/org/apache/lucene/facet
svn move
lucene/facet/src/test/org/apache/lucene/facet/enhancements/EnhancementsPayloadIteratorTest.java
lucene/demo/src/test/org/apache/lucene/facet/example
svn move
lucene/facet/src/test/org/apache/lucene/facet/search/TestTotalFacetCounts.java
lucene/demo/src/test/org/apache/lucene/facet/example
svn move
lucene/facet/src/test/org/apache/lucene/facet/search/TestTotalFacetCountsCache.java
lucene/demo/src/test/org/apache/lucene/facet/example
svn move
lucene/facet/src/test/org/apache/lucene/facet/index/FacetsPayloadProcessorProviderTest.java
lucene/demo/src/test/org/apache/lucene/facet/example
{noformat}
facet module should have no dependencies, consolidate examples into demo/
-
Key: LUCENE-3998
URL: https://issues.apache.org/jira/browse/LUCENE-3998
Project: Lucene - Java
Issue Type: Task
Components: modules/facet
Affects Versions: 4.0
Reporter: Robert Muir
Attachments: LUCENE-3998.patch
currently facets depends on analyzers-common, but this is unnecessary.
additionally it has a nice examples/ package (even with javadocs! are they
actually seen anywhere?!),
as well as tests for those examples.
I think instead it would be better if facet/ had no dependencies,
and if examples+examples tests were in demo/.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256632#comment-13256632 ] Steven Rowe commented on SOLR-3358: --- Ryan, Maven compile is failing, AFAICT as a result of your commit: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/459/consoleText Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3374) HttpClient jar not included in distribution
HttpClient jar not included in distribution --- Key: SOLR-3374 URL: https://issues.apache.org/jira/browse/SOLR-3374 Project: Solr Issue Type: Improvement Components: clients - java Affects Versions: 3.6 Reporter: Roger Håkansson Priority: Minor In 3.6 CommonsHttpSolrServer is deprecated in favor for HttpSolrServer however in the distribution under solrj-lib, non of the required jar files for HttpClient 4.x is included -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3995) In LuceneTestCase.beforeClass, make a new random (also using the class hashcode) to vary defaults
[
https://issues.apache.org/jira/browse/LUCENE-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256650#comment-13256650
]
Dawid Weiss commented on LUCENE-3995:
-
Robert, this would mean it works fine, right (note dumped randomVal for each
suite)?
{noformat}
Executing 296 suites with 4 JVMs.
Suite: org.apache.lucene.util.TestCloseableThreadLocal
(@BeforeClass output)
1 randomVal: 9
1
OK 0.05s J1 | TestCloseableThreadLocal.testDefaultValueWithoutSetting
OK 0.01s J1 | TestCloseableThreadLocal.testInitValue
OK 0.01s J1 | TestCloseableThreadLocal.testNullValue
Completed on J1 in 0.27s, 3 tests
Suite: org.apache.lucene.util.TestTwoPhaseCommitTool
(@BeforeClass output)
1 randomVal: 6
1
OK 0.04s J2 | TestTwoPhaseCommitTool.testRollback
OK 0.01s J2 | TestTwoPhaseCommitTool.testNullTPCs
OK 0.01s J2 | TestTwoPhaseCommitTool.testWrapper
OK 0.01s J2 | TestTwoPhaseCommitTool.testPrepareThenCommit
Completed on J2 in 0.37s, 4 tests
Suite: org.apache.lucene.util.TestNamedSPILoader
(@BeforeClass output)
1 randomVal: 7
1
OK 0.04s J0 | TestNamedSPILoader.testAvailableServices
OK 0.01s J0 | TestNamedSPILoader.testBogusLookup
OK 0.01s J0 | TestNamedSPILoader.testLookup
Completed on J0 in 0.34s, 3 tests
Suite: org.apache.lucene.util.TestSmallFloat
(@BeforeClass output)
1 randomVal: 2
1
OK 0.20s J3 | TestSmallFloat.testFloatToByte
OK 0.01s J3 | TestSmallFloat.testByteToFloat
Completed on J3 in 0.48s, 2 tests
Suite: org.apache.lucene.index.TestTerm
(@BeforeClass output)
1 randomVal: 0
1
{noformat}
In LuceneTestCase.beforeClass, make a new random (also using the class
hashcode) to vary defaults
-
Key: LUCENE-3995
URL: https://issues.apache.org/jira/browse/LUCENE-3995
Project: Lucene - Java
Issue Type: Improvement
Components: general/test
Affects Versions: 4.0
Reporter: Robert Muir
Assignee: Dawid Weiss
In LuceneTestCase, we set many static defaults like:
* default codec
* default infostream impl
* default locale
* default timezone
* default similarity
Currently each test run gets a single seed for the run, which means for
example across one test run
every single test will have say, SimpleText + infostream=off + Locale=german
+ timezone=EDT + similarity=BM25
Because of that, we lose lots of basic mixed coverage across tests, and it
also means the unfortunate
individual who gets SimpleText or other slow options gets a REALLY SLOW test
run, rather than amortizing
this across all test runs.
We should at least make a new random (getRandom() ^ className.hashCode()) to
fix this so it works like before,
but unfortunately that only fixes it for LuceneTestCase.
Won't any subclasses that make random decisions in @BeforeClass (and we have
many) still have the same problem?
Maybe RandomizedRunner can instead be improved here?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3362) FacetComponent throws NPE when doing distributed query
[ https://issues.apache.org/jira/browse/SOLR-3362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256652#comment-13256652 ] Sami Siren commented on SOLR-3362: -- bq. OK, I just verified that this is not a problem with older trunk builds, so this was an issue introduced by the new http client 4 (upgraded on 3/29). Before that, we get a normal looking single-part post with correct encoding. What is the action the solrj client is doing here? FacetComponent throws NPE when doing distributed query -- Key: SOLR-3362 URL: https://issues.apache.org/jira/browse/SOLR-3362 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.0 Environment: RHEL lucene svn revision 1308309 Reporter: Jamie Johnson When executing a query against a field in my index I am getting the following exception The query I am executing is as follows: http://host:port/solr/collection1/select?q=bobfacet=truefacet.field=organization debugging the FacetComponent line 489 sfc is null SEVERE: java.lang.NullPointerException at org.apache.solr.handler.component.FacetComponent.refineFacets(FacetComponent.java:489) at org.apache.solr.handler.component.FacetComponent.handleResponses(FacetComponent.java:278) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:307) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1550) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:442) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:263) at org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337) at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:484) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119) at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:524) at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233) at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1065) at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:413) at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192) at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:999) at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:117) at org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:250) at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:149) at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:111) at org.eclipse.jetty.server.Server.handle(Server.java:351) at org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:454) at org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:47) at org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:890) at org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:944) at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:634) at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:230) at org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:66) at org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:254) at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:599) at org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:534) at java.lang.Thread.run(Thread.java:662) -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3995) In LuceneTestCase.beforeClass, make a new random (also using the class hashcode) to vary defaults
[ https://issues.apache.org/jira/browse/LUCENE-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256654#comment-13256654 ] Robert Muir commented on LUCENE-3995: - yeah that looks right to me. I think currently randomVal will stay the same. In LuceneTestCase.beforeClass, make a new random (also using the class hashcode) to vary defaults - Key: LUCENE-3995 URL: https://issues.apache.org/jira/browse/LUCENE-3995 Project: Lucene - Java Issue Type: Improvement Components: general/test Affects Versions: 4.0 Reporter: Robert Muir Assignee: Dawid Weiss In LuceneTestCase, we set many static defaults like: * default codec * default infostream impl * default locale * default timezone * default similarity Currently each test run gets a single seed for the run, which means for example across one test run every single test will have say, SimpleText + infostream=off + Locale=german + timezone=EDT + similarity=BM25 Because of that, we lose lots of basic mixed coverage across tests, and it also means the unfortunate individual who gets SimpleText or other slow options gets a REALLY SLOW test run, rather than amortizing this across all test runs. We should at least make a new random (getRandom() ^ className.hashCode()) to fix this so it works like before, but unfortunately that only fixes it for LuceneTestCase. Won't any subclasses that make random decisions in @BeforeClass (and we have many) still have the same problem? Maybe RandomizedRunner can instead be improved here? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3987) Ivy/maven config to pull from sonatype releases
[ https://issues.apache.org/jira/browse/LUCENE-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256657#comment-13256657 ] Dawid Weiss commented on LUCENE-3987: - After some deliberation I would like to add ivysettings.xml to test-framework module which would allow (this module) to fetch dependencies from an additional repository (sonatype releases). I will also add this to corresponding maven descriptor so these would be in sync. Maintenance-wise this is not an issue -- sonatype is mirroring to central so effectively they're the same but there is no lag between releases and syncs. Ivy/maven config to pull from sonatype releases --- Key: LUCENE-3987 URL: https://issues.apache.org/jira/browse/LUCENE-3987 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: ivy-sonatype.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-3987) Ivy/maven config to pull from sonatype releases
[ https://issues.apache.org/jira/browse/LUCENE-3987?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss updated LUCENE-3987: Attachment: LUCENE-3987.patch Patch with module-specific ivy settings and maven settings. Ivy/maven config to pull from sonatype releases --- Key: LUCENE-3987 URL: https://issues.apache.org/jira/browse/LUCENE-3987 Project: Lucene - Java Issue Type: Improvement Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Trivial Attachments: LUCENE-3987.patch, ivy-sonatype.patch -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Problem running all of a module's tests under IntelliJ: Wrong test finished.
Hi Steve, I think it should be all right now (checked on simple examples, didn't run full lucene suites). Let me know if this works for you. Dawid P.S. It's a long story why this was happening -- different assumptions by vendors concerning events passed to RunListeners... On Wed, Apr 18, 2012 at 2:08 PM, Steven A Rowe sar...@syr.edu wrote: Cool, thanks! -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Wednesday, April 18, 2012 7:44 AM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. I think I know what the problem is and I'm working on a fix. This may require you to set a property strictJunitCompatibilityIsStupid though... I'm not really keen on making what I consider flaws in JUnit a default behavior :) Dawid On Wed, Apr 18, 2012 at 12:05 AM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: Thanks Steve, I'll be bulk-fixing all the discovered issues tomorrow. I'll let you know if I figure out what's causing this. Dawid On Wed, Apr 18, 2012 at 12:00 AM, Steven A Rowe sar...@syr.edu wrote: Dawid, I have included in the IntelliJ IDEA configuration for Lucene/Solr a set of run configurations, one per module, that runs all tests in each module. After you have run ant idea at the top level, then opened the project in IntelliJ IDEA, then set up the JDK to use (the menu path to set up the JDK is printed to the terminal after you run ant idea) you should be able to see something similar to this: http://postimage.org/image/ivi5srd5v To the left of the triangular green arrow icon (which means: run the selected run configuration), there is a dropdown menu for run configurations. In the above-linked image, I've left-clicked on this dropdown, and the mouse is hovering over Module analyzers-common - this is one of the modules that exhibits the test running problem. Left-click on Module analyzers-common to set the active run configuration. After you do this, the run configuration dropdown will change to display this label. Then you can start the tests associated with this by clicking on the green triangular button to the right of the run configuration dropdown. When IntelliJ runs tests, it will first make the associated module and its dependent modules, then show a JUnit pane at the bottom of the window, with a tree of test suites and their tests on the left, and console output on the right. Let me know if you need more info. Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Tuesday, April 17, 2012 5:26 PM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. Steven can you send me a screenshot or something showing where I should click to get this failure? :) Dawid On Tue, Apr 17, 2012 at 6:04 PM, Steven A Rowe sar...@syr.edu wrote: Hi Dawid :) Do you use IntelliJ? There appears to be some form of bad interaction between the new RandomizedTesting library additions and IntelliJ's test runner. When I try to run all of an IntelliJ module's tests under IntelliJ, e.g. analyzers-common or lucene (including core and test-framework), not all tests run; those that don't run are reported as not started. The external test process reports Wrong test finished. (???) and then returns exit code -1. This behavior is relatively new - I don't think the modules/*-lucene/ move is the culprit (the IntelliJ lucene+test-framework module didn't move and it has this issue). Here's the output from running all analyzers-common tests: -- C:\Program Files\Java\jdk1.6.0_21\bin\java -ea -DtempDir=temp -Didea.launcher.port=7541 -Didea.launcher.bin.path=C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\bin -Dfile.encoding=UTF-8 -classpath C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\lib\idea_rt.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\plugins\junit\lib\junit-rt.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\alt-rt.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\jce.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\plugin.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\resources.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\rt.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\ext\dnsns.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\ext\localedata.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\ext\sunjce_provider.jar;C:\svn\lucene \d ev\trunk\lucene\build\analysis\analyzers-common\classes\test;C:\svn\ lu
[jira] [Resolved] (LUCENE-3993) Polishing annoyances from JUnit4
[ https://issues.apache.org/jira/browse/LUCENE-3993?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-3993. - Resolution: Fixed Reopen if any of these issues are still present. Polishing annoyances from JUnit4 Key: LUCENE-3993 URL: https://issues.apache.org/jira/browse/LUCENE-3993 Project: Lucene - Java Issue Type: Sub-task Components: general/build, general/test Reporter: Dawid Weiss Assignee: Dawid Weiss Priority: Minor Fix For: 4.0 - @Ignore and @TestGroup-ignored tests should report the reason much like assumption-ignored tests. https://github.com/carrotsearch/randomizedtesting/issues/82 - perturb randomness in @BeforeClass hooks so that bad apples are more evently distributed across suites. https://issues.apache.org/jira/browse/LUCENE-3995 - IntelliJ Idea test configs https://github.com/carrotsearch/randomizedtesting/issues/83 -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3995) In LuceneTestCase.beforeClass, make a new random (also using the class hashcode) to vary defaults
[ https://issues.apache.org/jira/browse/LUCENE-3995?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Dawid Weiss resolved LUCENE-3995. - Resolution: Fixed Fix Version/s: 4.0 Fixed in trunk. In LuceneTestCase.beforeClass, make a new random (also using the class hashcode) to vary defaults - Key: LUCENE-3995 URL: https://issues.apache.org/jira/browse/LUCENE-3995 Project: Lucene - Java Issue Type: Improvement Components: general/test Affects Versions: 4.0 Reporter: Robert Muir Assignee: Dawid Weiss Fix For: 4.0 In LuceneTestCase, we set many static defaults like: * default codec * default infostream impl * default locale * default timezone * default similarity Currently each test run gets a single seed for the run, which means for example across one test run every single test will have say, SimpleText + infostream=off + Locale=german + timezone=EDT + similarity=BM25 Because of that, we lose lots of basic mixed coverage across tests, and it also means the unfortunate individual who gets SimpleText or other slow options gets a REALLY SLOW test run, rather than amortizing this across all test runs. We should at least make a new random (getRandom() ^ className.hashCode()) to fix this so it works like before, but unfortunately that only fixes it for LuceneTestCase. Won't any subclasses that make random decisions in @BeforeClass (and we have many) still have the same problem? Maybe RandomizedRunner can instead be improved here? -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256675#comment-13256675
]
Steven Rowe commented on SOLR-3358:
---
bq. Ryan, Maven compile is failing, AFAICT as a result of your commit:
https://builds.apache.org/job/Lucene-Solr-Maven-trunk/459/consoleText
I just committed a fix: from solr-core POM, exclude {{log4j-over-slf4j}}
transitive dependency from solrj dependency. Compile/test works locally for me.
Capture Logging Events from JUL and Log4j
-
Key: SOLR-3358
URL: https://issues.apache.org/jira/browse/SOLR-3358
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch
The UI should be able to show the last few log messages. To support this, we
will need to register an Appender (log4j) or Handler
(JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3324) Put field name/type in the analysis URL
[ https://issues.apache.org/jira/browse/SOLR-3324?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256687#comment-13256687 ] Stefan Matheis (steffkes) commented on SOLR-3324: - bq. perhaps we can avoid this I checked this yesterday .. right now, the answer is simple: we can't. the browser is listening on the 'hashchange' event, which is triggered if we change the url (especially the hash, everything after the hash) So, we can change it .. then it will reload the page every time you toggle the verbose-option, but we have the setting in the url. don't know what is more important? a responsive UI or the possibility to bookmark the complete option-set? Put field name/type in the analysis URL Key: SOLR-3324 URL: https://issues.apache.org/jira/browse/SOLR-3324 Project: Solr Issue Type: Improvement Components: web gui Reporter: Ryan McKinley Fix For: 4.0 Attachments: SOLR-3324.patch, SOLR-3324.patch It would be nice to be able to link directly to a page that loads the right field in the analysis UI. This will also let us link the query-browser page to the analysis page -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256689#comment-13256689
]
Steven Rowe commented on SOLR-3358:
---
{quote}
My IntelliJ is complaining about compiling Log4jWatcher. I think its because of
the classpath collision of the log4j and log4j-over-slf4j jars. Both include a
org.apache.log4j.LogManager and org.apache.log4j.spi.LoggingEvent, yet they
aren't the same classes. Any thoughts here? I'm not sure we can have the jars
as they are.
{quote}
Ant compilation succeeds only because {{log4j}} is ordered before
{{log4j-over-slf4j}} in the classpath. This is bad.
Capture Logging Events from JUL and Log4j
-
Key: SOLR-3358
URL: https://issues.apache.org/jira/browse/SOLR-3358
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch
The UI should be able to show the last few log messages. To support this, we
will need to register an Appender (log4j) or Handler
(JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256694#comment-13256694 ] Ryan McKinley commented on SOLR-3358: - thanks steven I'm looking at the pom issue now. Ideally the -over-* will be optional dependencies in solrj, excluded from solr-core and included in the .war (this lets the end user decide what logging framework they actually use) For the ant build path, any suggestions? we can exclude it from core, and then add it back to the .war file. I'm not sure how to get the ivy stuff setup to have .war dependencies though. Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Reopened] (SOLR-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steven Rowe reopened SOLR-3358:
---
Reopening to fix Solr compilation classpath to exclude {{log4j-over-slf4j}}
Capture Logging Events from JUL and Log4j
-
Key: SOLR-3358
URL: https://issues.apache.org/jira/browse/SOLR-3358
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch
The UI should be able to show the last few log messages. To support this, we
will need to register an Appender (log4j) or Handler
(JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256704#comment-13256704
]
Steven Rowe commented on SOLR-3358:
---
bq. For the ant build path, any suggestions?
All {{solr/lib/}} jars are put on the compilation classpath via the
{{additional.dependencies}} path. I added {{log4j-over-slf4j}} to the exclude
list and compile/test for all solr+contribs succeeds:
{code:xml}
path id=additional.dependencies
- fileset dir=${common-solr.dir}/lib
excludes=${common.classpath.excludes}/
+ fileset dir=${common-solr.dir}/lib
+excludes=${common.classpath.excludes},log4j-over-slf4j*/
fileset dir=${common-solr.dir}/example/lib
excludes=${common.classpath.excludes}/
fileset dir=lib excludes=${common.classpath.excludes}
erroronmissingdir=false/
/path
{code}
bq. we can exclude it from core, and then add it back to the .war file. I'm not
sure how to get the ivy stuff setup to have .war dependencies though.
{{ant dist}} under {{solr/webapp/}}, which produces the .war, doesn't use
{{additional.dependencies}} - instead it uses {{common.classpath.excludes}}.
So I think with the above change, {{log4j-over-slf4j}} will continue to be
included in the .war.
Capture Logging Events from JUL and Log4j
-
Key: SOLR-3358
URL: https://issues.apache.org/jira/browse/SOLR-3358
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch
The UI should be able to show the last few log messages. To support this, we
will need to register an Appender (log4j) or Handler
(JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256708#comment-13256708
]
Steven Rowe commented on SOLR-3358:
---
bq. So I think with the above change, log4j-over-slf4j will continue to be
included in the .war.
Confirmed - after running {{ant dist}} from {{solr/webapp/}} with the above
change in {{solr/common-build.xml}}, I can see from running {{tar tvf
solr/dist/*.war}}:
{noformat}
...
481535 Wed Mar 31 00:25:34 EDT 2010 WEB-INF/lib/log4j-1.2.16.jar
20639 Mon Oct 31 18:46:50 EDT 2011 WEB-INF/lib/log4j-over-slf4j-1.6.4.jar
...
{noformat}
But as you can see, {{log4j}} is still there - is that intentional, Ryan?
Capture Logging Events from JUL and Log4j
-
Key: SOLR-3358
URL: https://issues.apache.org/jira/browse/SOLR-3358
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: SOLR-3358-logging.patch, SOLR-3358-logging.patch
The UI should be able to show the last few log messages. To support this, we
will need to register an Appender (log4j) or Handler
(JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-3358: Attachment: SOLR-3358-compile-path.patch Steven, do these .pom changes make sense to you? +1 on your additional.dependencies change The problem with idea build is that it includes everything in lib. The options I see are to either list the jars explicitly (leaving out -over-slf4j) or make a new lib folder under webapp. Thoughts? Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Issue Comment Edited] (SOLR-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256708#comment-13256708
]
Steven Rowe edited comment on SOLR-3358 at 4/18/12 5:14 PM:
bq. So I think with the above change, log4j-over-slf4j will continue to be
included in the .war.
Confirmed - after running {{ant dist}} from {{solr/webapp/}} with the above
change in {{solr/common-build.xml}}, I can see from running {{jar tvf
solr/dist/*.war}}:
{noformat}
...
481535 Wed Mar 31 00:25:34 EDT 2010 WEB-INF/lib/log4j-1.2.16.jar
20639 Mon Oct 31 18:46:50 EDT 2011 WEB-INF/lib/log4j-over-slf4j-1.6.4.jar
...
{noformat}
But as you can see, {{log4j}} is still there - is that intentional, Ryan?
was (Author: steve_rowe):
bq. So I think with the above change, log4j-over-slf4j will continue to be
included in the .war.
Confirmed - after running {{ant dist}} from {{solr/webapp/}} with the above
change in {{solr/common-build.xml}}, I can see from running {{tar tvf
solr/dist/*.war}}:
{noformat}
...
481535 Wed Mar 31 00:25:34 EDT 2010 WEB-INF/lib/log4j-1.2.16.jar
20639 Mon Oct 31 18:46:50 EDT 2011 WEB-INF/lib/log4j-over-slf4j-1.6.4.jar
...
{noformat}
But as you can see, {{log4j}} is still there - is that intentional, Ryan?
Capture Logging Events from JUL and Log4j
-
Key: SOLR-3358
URL: https://issues.apache.org/jira/browse/SOLR-3358
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch,
SOLR-3358-logging.patch
The UI should be able to show the last few log messages. To support this, we
will need to register an Appender (log4j) or Handler
(JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256710#comment-13256710 ] Robert Muir commented on SOLR-3358: --- hmm, 4 logging jars, excluding certain jars for different things here and there, this creates a lot of complexity and dependency management. log4j-over-slf4j already has the log4j api, it must for it to work (http://www.slf4j.org/legacy.html) so I don't understand why the log4j jar is being added! Why is this necessary? If we are going to add log4j, then slf4j should removed, otherwise the whole purpose of a logging facade is defeated. One of these must go. Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: PyLucene use JCC shared object by default
Hi Andi, My question is: would it be possible for JCC to be compiled as a shared library in PyLucene (by default) instead of being compiled in as a static object? If JCC was compiled as a shared object and PyLucene linked to it, my organization (and possibly others) would be able to maintain and release custom extensions for PyLucene written in C++. This would simplify the use and need for maintaining a custom installation of PyLucene linked against JCC. The reason for our approach is because we primarily use/write Python with C and C++ extension. On Tue, Apr 17, 2012 at 7:39 PM, Andi Vajda va...@apache.org wrote: Hi Caleb, On Tue, 17 Apr 2012, Caleb Burns wrote: I've finished the process at my organization of re-implementing SOLR's faceting algorithm (in C++). We would like the public at large to have access to the work we've done and plan to do. In order for this to be a real possibility the code needs to be built against and use the same JVM as the PyLucene installation does. The most logical way we feel to have this accomplished is by having PyLucenes' default installation use JCC as a Shared Object. We have yet more plans to extend and provide utilities that work with PyLucene, but this all hinges on having the shared object. The only alternative methodology would require the bundling of our source with the PyLucene project itself as a fork. We are eager to start open sourcing our work, so please let us know what would be the best way to integrate our work. Ok, so what is your question ? PyLucene's shared mode also depends on JCC's shared library. Is your question about what the default should be ? Andi.. -- Caleb Burns Developer | Riders Discount
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256717#comment-13256717
]
Steven Rowe commented on SOLR-3358:
---
bq. Steven, do these .pom changes make sense to you?
Yes, but there is a syntax issue - all of these:
{code:xml}
scopeoptional/scope
{code}
should instead be:
{code:xml}
optionaltrue/optional
{code}
Capture Logging Events from JUL and Log4j
-
Key: SOLR-3358
URL: https://issues.apache.org/jira/browse/SOLR-3358
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch,
SOLR-3358-logging.patch
The UI should be able to show the last few log messages. To support this, we
will need to register an Appender (log4j) or Handler
(JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256723#comment-13256723 ] Ryan McKinley commented on SOLR-3358: - bq. so I don't understand why the log4j jar is being added! Why is this necessary? The log4j-over-slf4j.jar only wraps the calls to write events, it does not wrap anything for handling events (Appender and LoggingEvent). Ideally log4j would only be in the classpath for: https://svn.apache.org/repos/asf/lucene/dev/trunk/solr/core/src/java/org/apache/solr/logging/log4j/ The point of this is to capture events if the end user binds JUL or Log4j. Alternatively I could put the log4j implementation elsewhere, but that seems kinda silly since lots of people actually use log4j Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Problem running all of a module's tests under IntelliJ: Wrong test finished.
Yes! analyzers-common module tests all run now (they didn't before your LUCENE-3993 commit); I'm running all of the others now. Thanks, Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Wednesday, April 18, 2012 12:00 PM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. Hi Steve, I think it should be all right now (checked on simple examples, didn't run full lucene suites). Let me know if this works for you. Dawid P.S. It's a long story why this was happening -- different assumptions by vendors concerning events passed to RunListeners... On Wed, Apr 18, 2012 at 2:08 PM, Steven A Rowe sar...@syr.edu wrote: Cool, thanks! -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Wednesday, April 18, 2012 7:44 AM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. I think I know what the problem is and I'm working on a fix. This may require you to set a property strictJunitCompatibilityIsStupid though... I'm not really keen on making what I consider flaws in JUnit a default behavior :) Dawid On Wed, Apr 18, 2012 at 12:05 AM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: Thanks Steve, I'll be bulk-fixing all the discovered issues tomorrow. I'll let you know if I figure out what's causing this. Dawid On Wed, Apr 18, 2012 at 12:00 AM, Steven A Rowe sar...@syr.edu wrote: Dawid, I have included in the IntelliJ IDEA configuration for Lucene/Solr a set of run configurations, one per module, that runs all tests in each module. After you have run ant idea at the top level, then opened the project in IntelliJ IDEA, then set up the JDK to use (the menu path to set up the JDK is printed to the terminal after you run ant idea) you should be able to see something similar to this: http://postimage.org/image/ivi5srd5v To the left of the triangular green arrow icon (which means: run the selected run configuration), there is a dropdown menu for run configurations. In the above-linked image, I've left-clicked on this dropdown, and the mouse is hovering over Module analyzers-common - this is one of the modules that exhibits the test running problem. Left-click on Module analyzers-common to set the active run configuration. After you do this, the run configuration dropdown will change to display this label. Then you can start the tests associated with this by clicking on the green triangular button to the right of the run configuration dropdown. When IntelliJ runs tests, it will first make the associated module and its dependent modules, then show a JUnit pane at the bottom of the window, with a tree of test suites and their tests on the left, and console output on the right. Let me know if you need more info. Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Tuesday, April 17, 2012 5:26 PM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. Steven can you send me a screenshot or something showing where I should click to get this failure? :) Dawid On Tue, Apr 17, 2012 at 6:04 PM, Steven A Rowe sar...@syr.edu wrote: Hi Dawid :) Do you use IntelliJ? There appears to be some form of bad interaction between the new RandomizedTesting library additions and IntelliJ's test runner. When I try to run all of an IntelliJ module's tests under IntelliJ, e.g. analyzers-common or lucene (including core and test-framework), not all tests run; those that don't run are reported as not started. The external test process reports Wrong test finished. (???) and then returns exit code -1. This behavior is relatively new - I don't think the modules/*-lucene/ move is the culprit (the IntelliJ lucene+test-framework module didn't move and it has this issue). Here's the output from running all analyzers-common tests: -- C:\Program Files\Java\jdk1.6.0_21\bin\java -ea -DtempDir=temp -Didea.launcher.port=7541 -Didea.launcher.bin.path=C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\bin -Dfile.encoding=UTF-8 -classpath C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\lib\idea_rt.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\plugins\junit\lib\junit-rt.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\alt-rt.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\charsets.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\deploy.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\javaws.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\jce.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\jsse.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\management-agent.jar;C:\Program Files\Java\jdk1.6.0_21\jre\lib\plugin.jar;C:\Program
[jira] [Commented] (LUCENE-3957) Document precision requirements of setBoost calls
[ https://issues.apache.org/jira/browse/LUCENE-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256736#comment-13256736 ] Jordi Salvat i Alabart commented on LUCENE-3957: Wherever, but please increase exposure of this detail, for the sake of those who're coming in later. It's a VERY long and winded way between setting a $docBoost in a SolR dataSource transformer script and the current location of this information. Would be kind of acceptable if the value was held with a couple of decimal digits of precision, but the default (3-bit) implementation doesn't hold even ONE digit, making the behaviour really shocking -- specially since the boost value is not directly visible, but only through its impact on search scores. Document precision requirements of setBoost calls - Key: LUCENE-3957 URL: https://issues.apache.org/jira/browse/LUCENE-3957 Project: Lucene - Java Issue Type: Improvement Components: general/javadocs Affects Versions: 3.5 Reporter: Jordi Salvat i Alabart The behaviour of index-time boosts seems pretty erratic (e.g. a boost of 8.0 produces the exact same score as a boost of 9.0) until you become aware that these factors end up encoded in a single byte, with a three-bit mantissa. This consumed a whole day of research for us, and I still believe we were lucky to spot it, given how deeply dug into the code documentation this information is. I suggest adding a small note to the JavaDoc of setBoost methods in Document, Fieldable, FieldInvertState, and possibly AbstractField, Field, and NumericField. Suggested text: Note that all index-time boost values end up encoded using Similarity.encodeNormValue, with a 3-bit mantissa -- so differences in the boost value of less than 25% may easily be rounded away. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256739#comment-13256739 ] Uwe Schindler commented on SOLR-3358: - Ryan: But you have now a classpath conflict. Depending on the order of jar files in filesystem and order of jar files resulting by that undefinedness, it can happen that log4j events are no longer transferred to slf4j (if user does *not* use log4j). The log4j-over-slf is just a catcher for compatibility with external libs bundeled with Solr, that use log4j as their logging framework (it emulates log4j). The user has to sort out what chains he need to get correct logging, means: slf4 main jar, the delegator to log4j and log4j to do the actual work, or alternatively log4j-over-slf4j (to catch 3rd party logging events) and sl4fj (like it was before), that will log to JUL or nowhere. Theoretically maybe commons-logging cather is also needed for some 3rd party libs like commons-digester. *I would like that we revert this commit and discuss the logging again!* This will be a pain for all WAR users and is already wrong because of duplicate class files in classpath leading to bugs or maybe even stack overflows because of logging-loops (I have seen that already, one logging framework delegates to another one and finally to itsself). Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module
[ https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256740#comment-13256740 ] Martijn van Groningen commented on LUCENE-3997: --- +1! Good idea. Maybe we can move FunctionValues and ValueSource from the queries modules to core? Then grouping module doesn't have to depend on the queries module. join module should not depend on grouping module Key: LUCENE-3997 URL: https://issues.apache.org/jira/browse/LUCENE-3997 Project: Lucene - Java Issue Type: Task Affects Versions: 4.0 Reporter: Robert Muir Fix For: 4.0 Attachments: LUCENE-3997.patch, LUCENE-3997.patch I think TopGroups/GroupDocs should simply be in core? Both grouping and join modules use these trivial classes, but join depends on grouping just for them. I think its better that we try to minimize these inter-module dependencies. Of course, another option is to combine grouping and join into one module, but last time i brought that up nobody could agree on a name. Anyway I think the change is pretty clean: its similar to having basic stuff like Analyzer.java in core, so other things can work with Analyzer without depending on any specific implementing modules. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: svn commit: r1327576 - /lucene/dev/trunk/dev-tools/maven/pom.xml.template
Thanks Ryan! Dawid On Wed, Apr 18, 2012 at 6:46 PM, r...@apache.org wrote: Author: ryan Date: Wed Apr 18 16:46:43 2012 New Revision: 1327576 URL: http://svn.apache.org/viewvc?rev=1327576view=rev Log: update randomized runner pom Modified: lucene/dev/trunk/dev-tools/maven/pom.xml.template Modified: lucene/dev/trunk/dev-tools/maven/pom.xml.template URL: http://svn.apache.org/viewvc/lucene/dev/trunk/dev-tools/maven/pom.xml.template?rev=1327576r1=1327575r2=1327576view=diff == --- lucene/dev/trunk/dev-tools/maven/pom.xml.template (original) +++ lucene/dev/trunk/dev-tools/maven/pom.xml.template Wed Apr 18 16:46:43 2012 @@ -376,7 +376,7 @@ dependency groupIdcom.carrotsearch.randomizedtesting/groupId artifactIdrandomizedtesting-runner/artifactId - version1.2.0/version + version1.3.0/version /dependency /dependencies /dependencyManagement - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256741#comment-13256741
]
Steven Rowe commented on SOLR-3358:
---
bq. The problem with idea build is that it includes everything in lib. The
options I see are to either list the jars explicitly (leaving out -over-slf4j)
or make a new lib folder under webapp. Thoughts?
I'd rather not list the jars explicitly - IntelliJ dependency configuration has
been quite stable because whole directories are specified, and I'd rather not
change that if possible.
So my vote is to make a new lib folder under webapp.
(I can confirm, though, that explicitly listing all jars except
{{log4j-over-slf4j}} allows compilation and testing to succeed.)
Capture Logging Events from JUL and Log4j
-
Key: SOLR-3358
URL: https://issues.apache.org/jira/browse/SOLR-3358
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch,
SOLR-3358-logging.patch
The UI should be able to show the last few log messages. To support this, we
will need to register an Appender (log4j) or Handler
(JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module
[
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256744#comment-13256744
]
Robert Muir commented on LUCENE-3997:
-
{quote}
Maybe we can move FunctionValues and ValueSource from the queries modules to
core? Then grouping module doesn't have to depend on the queries module.
{quote}
+1 (I didn't even think of that or investigate it yet though, but at a glance
it looks like the right thing to do).
join module should not depend on grouping module
Key: LUCENE-3997
URL: https://issues.apache.org/jira/browse/LUCENE-3997
Project: Lucene - Java
Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
Fix For: 4.0
Attachments: LUCENE-3997.patch, LUCENE-3997.patch
I think TopGroups/GroupDocs should simply be in core?
Both grouping and join modules use these trivial classes, but join depends on
grouping just for them.
I think its better that we try to minimize these inter-module dependencies.
Of course, another option is to combine grouping and join into one module, but
last time i brought that up nobody could agree on a name.
Anyway I think the change is pretty clean: its similar to having basic stuff
like Analyzer.java in core,
so other things can work with Analyzer without depending on any specific
implementing modules.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: Problem running all of a module's tests under IntelliJ: Wrong test finished.
All modules' tests run (and succeed) for me now (after hacking the Solr library to exclude log4j-over-slf4j by explicitly listing all jars except l-over-s under solr/lib/). Thanks again! - Steve -Original Message- From: Steven A Rowe [mailto:sar...@syr.edu] Sent: Wednesday, April 18, 2012 1:30 PM To: dev@lucene.apache.org Subject: RE: Problem running all of a module's tests under IntelliJ: Wrong test finished. Yes! analyzers-common module tests all run now (they didn't before your LUCENE-3993 commit); I'm running all of the others now. Thanks, Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Wednesday, April 18, 2012 12:00 PM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. Hi Steve, I think it should be all right now (checked on simple examples, didn't run full lucene suites). Let me know if this works for you. Dawid P.S. It's a long story why this was happening -- different assumptions by vendors concerning events passed to RunListeners... On Wed, Apr 18, 2012 at 2:08 PM, Steven A Rowe sar...@syr.edu wrote: Cool, thanks! -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Wednesday, April 18, 2012 7:44 AM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. I think I know what the problem is and I'm working on a fix. This may require you to set a property strictJunitCompatibilityIsStupid though... I'm not really keen on making what I consider flaws in JUnit a default behavior :) Dawid On Wed, Apr 18, 2012 at 12:05 AM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: Thanks Steve, I'll be bulk-fixing all the discovered issues tomorrow. I'll let you know if I figure out what's causing this. Dawid On Wed, Apr 18, 2012 at 12:00 AM, Steven A Rowe sar...@syr.edu wrote: Dawid, I have included in the IntelliJ IDEA configuration for Lucene/Solr a set of run configurations, one per module, that runs all tests in each module. After you have run ant idea at the top level, then opened the project in IntelliJ IDEA, then set up the JDK to use (the menu path to set up the JDK is printed to the terminal after you run ant idea) you should be able to see something similar to this: http://postimage.org/image/ivi5srd5v To the left of the triangular green arrow icon (which means: run the selected run configuration), there is a dropdown menu for run configurations. In the above-linked image, I've left-clicked on this dropdown, and the mouse is hovering over Module analyzers-common - this is one of the modules that exhibits the test running problem. Left-click on Module analyzers-common to set the active run configuration. After you do this, the run configuration dropdown will change to display this label. Then you can start the tests associated with this by clicking on the green triangular button to the right of the run configuration dropdown. When IntelliJ runs tests, it will first make the associated module and its dependent modules, then show a JUnit pane at the bottom of the window, with a tree of test suites and their tests on the left, and console output on the right. Let me know if you need more info. Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Tuesday, April 17, 2012 5:26 PM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. Steven can you send me a screenshot or something showing where I should click to get this failure? :) Dawid On Tue, Apr 17, 2012 at 6:04 PM, Steven A Rowe sar...@syr.edu wrote: Hi Dawid :) Do you use IntelliJ? There appears to be some form of bad interaction between the new RandomizedTesting library additions and IntelliJ's test runner. When I try to run all of an IntelliJ module's tests under IntelliJ, e.g. analyzers-common or lucene (including core and test-framework), not all tests run; those that don't run are reported as not started. The external test process reports Wrong test finished. (???) and then returns exit code -1. This behavior is relatively new - I don't think the modules/*-lucene/ move is the culprit (the IntelliJ lucene+test-framework module didn't move and it has this issue). Here's the output from running all analyzers-common tests: -- C:\Program Files\Java\jdk1.6.0_21\bin\java -ea -DtempDir=temp -Didea.launcher.port=7541 -Didea.launcher.bin.path=C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\bin -Dfile.encoding=UTF-8 -classpath C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\lib\idea_rt.jar;C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\plugins\junit\lib\junit-rt.jar;C:\Program
[jira] [Commented] (LUCENE-3957) Document precision requirements of setBoost calls
[
https://issues.apache.org/jira/browse/LUCENE-3957?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256760#comment-13256760
]
Robert Muir commented on LUCENE-3957:
-
I don't understand why its long and winded, its documented in tons of places in
lucene,
in-fact its actually over-specified in file-formats, for example, because even
in 3.5
the encoding of the normalization byte is an implementation detail of the
Similarity:
its just that you can only use a single byte.
In trunk its definitely overspecified since besides the above, the Similarity
can use
more than a byte if it wants to.
1. Main website (scoring):
http://lucene.apache.org/core/old_versioned_docs/versions/3_5_0/scoring.html
{noformat}
Indexing time boosts are preprocessed for storage efficiency and written to the
directory (when writing the document) in a single byte (!) as follows.
...
This composition of 1-byte representation of norms...
...
Encoding and decoding of the resulted float norm in a single byte are done by
the static methods of the class Similarity: encodeNorm() and decodeNorm(). Due
to loss of precision, it is not guaranteed that decode(encode(x)) = x, e.g.
decode(encode(0.89)) = 0.75. At scoring (search) time, this norm is brought
into the score of document as norm(t, d), as shown by the formula in
Similarity.
{noformat}
2. Main website (file formats):
http://lucene.apache.org/core/old_versioned_docs/versions/3_5_0/fileformats.html#Normalization%20Factors
{noformat}
Each byte encodes a floating point value. Bits 0-2 contain the 3-bit mantissa,
and bits 3-8 contain the 5-bit exponent.
These are converted to an IEEE single float value as follows:
...
{noformat}
3. Javadocs (Similarity):
http://lucene.apache.org/core/old_versioned_docs/versions/3_5_0/api/core/org/apache/lucene/search/Similarity.html
{noformat}
However the resulted norm value is encoded as a single byte before being
stored. At search time, the norm byte value is read from the index directory
and decoded back to a float norm value. This encoding/decoding, while reducing
index size, comes with the price of precision loss...
Compression of norm values to a single byte saves memory at search time,
because once a field is referenced at search time, its norms - for all
documents - are maintained in memory.
The rationale supporting such lossy compression of norm values is that given
the difficulty (and inaccuracy) of users to express their true information need
by a query, only big differences matter.
{noformat}
Document precision requirements of setBoost calls
-
Key: LUCENE-3957
URL: https://issues.apache.org/jira/browse/LUCENE-3957
Project: Lucene - Java
Issue Type: Improvement
Components: general/javadocs
Affects Versions: 3.5
Reporter: Jordi Salvat i Alabart
The behaviour of index-time boosts seems pretty erratic (e.g. a boost of 8.0
produces the exact same score as a boost of 9.0) until you become aware that
these factors end up encoded in a single byte, with a three-bit mantissa.
This consumed a whole day of research for us, and I still believe we were
lucky to spot it, given how deeply dug into the code documentation this
information is.
I suggest adding a small note to the JavaDoc of setBoost methods in Document,
Fieldable, FieldInvertState, and possibly AbstractField, Field, and
NumericField.
Suggested text:
Note that all index-time boost values end up encoded using
Similarity.encodeNormValue, with a 3-bit mantissa -- so differences in the
boost value of less than 25% may easily be rounded away.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256762#comment-13256762 ] Ryan McKinley commented on SOLR-3358: - bq. *I would like that we revert this commit and discuss the logging again!* I'll pull out the log4j implementation, but leave in the JUL one -- is that OK for now? or take out the whole thing? Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module
[ https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256765#comment-13256765 ] Yonik Seeley commented on LUCENE-3997: -- I think that if you try to make no modules depend on other modules, you'll end up just pulling pretty much everything into core. Also, the function query stuff is supposed to be marked as experimental - the notice only got added to FunctionQuery (I think?), so it should be applied to FunctionValues and ValueSource if they are moved to core. join module should not depend on grouping module Key: LUCENE-3997 URL: https://issues.apache.org/jira/browse/LUCENE-3997 Project: Lucene - Java Issue Type: Task Affects Versions: 4.0 Reporter: Robert Muir Fix For: 4.0 Attachments: LUCENE-3997.patch, LUCENE-3997.patch I think TopGroups/GroupDocs should simply be in core? Both grouping and join modules use these trivial classes, but join depends on grouping just for them. I think its better that we try to minimize these inter-module dependencies. Of course, another option is to combine grouping and join into one module, but last time i brought that up nobody could agree on a name. Anyway I think the change is pretty clean: its similar to having basic stuff like Analyzer.java in core, so other things can work with Analyzer without depending on any specific implementing modules. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module
[
https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256772#comment-13256772
]
Robert Muir commented on LUCENE-3997:
-
{quote}
I think that if you try to make no modules depend on other modules, you'll end
up just pulling pretty much everything into core.
{quote}
I don't think we should pull everything into core, but if we pull in the simple
abstract APIs we can
have a more pluggable API: just like the abstract Analyzer api is in core,
which Highlighter uses,
but you can highlight UIMA or Japanese or ICU or whatever analyzers this way...
join module should not depend on grouping module
Key: LUCENE-3997
URL: https://issues.apache.org/jira/browse/LUCENE-3997
Project: Lucene - Java
Issue Type: Task
Affects Versions: 4.0
Reporter: Robert Muir
Fix For: 4.0
Attachments: LUCENE-3997.patch, LUCENE-3997.patch
I think TopGroups/GroupDocs should simply be in core?
Both grouping and join modules use these trivial classes, but join depends on
grouping just for them.
I think its better that we try to minimize these inter-module dependencies.
Of course, another option is to combine grouping and join into one module, but
last time i brought that up nobody could agree on a name.
Anyway I think the change is pretty clean: its similar to having basic stuff
like Analyzer.java in core,
so other things can work with Analyzer without depending on any specific
implementing modules.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: svn commit: r1327606 - in /lucene/dev/trunk/lucene: README.txt build.xml
Thanks, you are the best! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: rm...@apache.org [mailto:rm...@apache.org] Sent: Wednesday, April 18, 2012 8:22 PM To: comm...@lucene.apache.org Subject: svn commit: r1327606 - in /lucene/dev/trunk/lucene: README.txt build.xml Author: rmuir Date: Wed Apr 18 18:22:18 2012 New Revision: 1327606 URL: http://svn.apache.org/viewvc?rev=1327606view=rev Log: LUCENE-3977: reduce javadocs triplication to only duplication Modified: lucene/dev/trunk/lucene/README.txt lucene/dev/trunk/lucene/build.xml Modified: lucene/dev/trunk/lucene/README.txt URL: http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/README.txt?rev=13276 06r1=1327605r2=1327606view=diff == --- lucene/dev/trunk/lucene/README.txt (original) +++ lucene/dev/trunk/lucene/README.txt Wed Apr 18 18:22:18 2012 @@ -19,9 +19,6 @@ Files are organized by module, for examp core/lucene- core-XX.jar The compiled core Lucene library. -core/lucene-core-XX-javadoc.jar - The Javadoc jar for the compiled core Lucene library. - Additional modules contain the same structure: analysis/common/: Analyzers for indexing content in different languages and domains Modified: lucene/dev/trunk/lucene/build.xml URL: http://svn.apache.org/viewvc/lucene/dev/trunk/lucene/build.xml?rev=1327606 r1=1327605r2=1327606view=diff == --- lucene/dev/trunk/lucene/build.xml (original) +++ lucene/dev/trunk/lucene/build.xml Wed Apr 18 18:22:18 2012 @@ -28,7 +28,7 @@ patternset id=binary.build.dist.patterns includes=docs/,**/*.jar,**/*.war - excludes=poms/**,**/*-src.jar + excludes=poms/**,**/*-src.jar,**/*-javadoc.jar / patternset id=binary.root.dist.patterns includes=LICENSE.txt,NOTICE.txt,README.txt, - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: PyLucene use JCC shared object by default
Hi Caleb, On Apr 18, 2012, at 10:18, Caleb Burns ca...@ridersdiscount.com wrote: My question is: would it be possible for JCC to be compiled as a shared library in PyLucene (by default) instead of being compiled in as a static object? It cannot be the default as shared mode (the mode where JCC has a shared library component) is not supported on all operating systems where PyLucene/JCC is. It currently works on Mac OS X, Windows and Linux (and on Linux with a patch to setuptools). Other operating systems need to solve the building a regular shared library -as opposed to a python extension shared library - via setuptools first before shared mode can be supported there. Where the local environment (operating system and presence of setuptools) permits, JCC already defaults to this shared mode. This is why, for example, on Linux, you are presented with the patching of setuptools required to make the building of a regular shared library work, when first building JCC there. If JCC was compiled as a shared object and PyLucene linked to it, my organization (and possibly others) would be able to maintain and release custom extensions for PyLucene written in C++. This would simplify the use and need for maintaining a custom installation of PyLucene linked against JCC. The reason for our approach is because we primarily use/write Python with C and C++ extension. Out of curiosity, why did you rewrite this Solr module in C++ instead of isolating its Java classes into a jar file and generating C++/Python wrappers for it using JCC ? Andi.. On Tue, Apr 17, 2012 at 7:39 PM, Andi Vajda va...@apache.org wrote: Hi Caleb, On Tue, 17 Apr 2012, Caleb Burns wrote: I've finished the process at my organization of re-implementing SOLR's faceting algorithm (in C++). We would like the public at large to have access to the work we've done and plan to do. In order for this to be a real possibility the code needs to be built against and use the same JVM as the PyLucene installation does. The most logical way we feel to have this accomplished is by having PyLucenes' default installation use JCC as a Shared Object. We have yet more plans to extend and provide utilities that work with PyLucene, but this all hinges on having the shared object. The only alternative methodology would require the bundling of our source with the PyLucene project itself as a fork. We are eager to start open sourcing our work, so please let us know what would be the best way to integrate our work. Ok, so what is your question ? PyLucene's shared mode also depends on JCC's shared library. Is your question about what the default should be ? Andi.. -- Caleb Burns Developer | Riders Discount
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256796#comment-13256796 ] Ryan McKinley commented on SOLR-3358: - log4j implementation pulled out in r1327608 Let me know if you want me to pull out the whole thing... bq. This will be a pain for all WAR users Note the .war does not include log4j.jar The aim is to provide a log4j implementation that can be used *if* the end user implements logging with log4j. Again, I am happy to put this elsewhere, but given that log4j is pretty common it would be nice to make it work out-of-the-box The first question is if we want to support log4j out of the box. If so, I think the right approach is to add a new lib folder to webapp and put all the slf4j-over .jar files in there Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: AW: PyLucene use JCC shared object by default
Hi Thomas, On Apr 18, 2012, at 6:31, Thomas Koch k...@orbiteam.de wrote: Hi, sounds like an interesting project – may I ask what you actually implemented and what’s the motivation (e.g. performance?)? I’ve started to experiment with the Facet support in Lucene (actually in PyLucene – ported an example to Python) and found that facetted search support in Lucene looks powerful (though API is still said to be ‘experimental’ and I can’t say anything about performance yet). I’m talking about the org.apache.lucene.facet.* packages – part of the contrib part of Lucene and available as JARs that’s accessible in PyLucene as well. I’m not that familiar with Solr but AFAIK it’s based on Lucene (Java) and should (hopefully) use the same Java code for its facet search support. Of course Solr adds some nice configuration support and web GUI to Lucene, but the ‘core’ search is built on Lucene (to my knowledge). So did you re-implement the Lucene facet search/index code (like TaxonomyReader/Writer, FacetRequest stuff etc.) in C++ or what part of Solr?? Regarding Facet support in PyLucene I can share the samples I’ve ‘ported’ to Python so far. There’s still a patch pending for JavaList (required by facet features) which I come back to later on this list (still some open issues). Hopefully this can be included in the PyLucene 3.6 version … Lucene 3.6 just got released a few days ago. Apart from your patch, the PyLucene 3.6 release is ready. I'm about to go offline (email only) for a week. Let's revisit this patch then (first week of May). It's not blocking the release right now as, even if I sent out a release candidate for a vote, the three business days required for this would take this into the time I'm away. Out of curiosity, why is this patch tied to the facetting module ? Can't you use the regular Java List implementations with it instead of a wrapped Python list ? If there are no wrappers for the classes you want, it's certainly easier to add them and they would provide a more efficient operation as Java code (the facet module) working with them wouldn't have to cross the VM barriers for each and every access into these lists. Andi.. Regards Thomas -- OrbiTeam Software GmbH Co. KG Germany http://www.orbiteam.de Von: Caleb Burns [mailto:ca...@ridersdiscount.com] Gesendet: Dienstag, 17. April 2012 21:16 An: pylucene-...@lucene.apache.org Betreff: PyLucene use JCC shared object by default Hi, I've finished the process at my organization of re-implementing SOLR's faceting algorithm (in C++). We would like the public at large to have access to the work we've done and plan to do. In order for this to be a real possibility the code needs to be built against and use the same JVM as the PyLucene installation does. The most logical way we feel to have this accomplished is by having PyLucenes' default installation use JCC as a Shared Object. We have yet more plans to extend and provide utilities that work with PyLucene, but this all hinges on having the shared object. The only alternative methodology would require the bundling of our source with the PyLucene project itself as a fork. We are eager to start open sourcing our work, so please let us know what would be the best way to integrate our work. -- Caleb Burns Developer | Riders Discount 866.931.6644 x851 | www.RidersDiscount.com Deal of the Day
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256815#comment-13256815 ] Robert Muir commented on SOLR-3358: --- I'm gonna dodge your question about 'do we support logging framework X' because i don't really care about logging, i just piped up because i care about the build or release packaging being complicated. The issue stumbles upon an existing problem actually: the solr dependencies and compilation classpaths are already quite confusing: * solr tests suck in huge classpaths from solr/lib and example/lib and other places: not really testing the 'desired classpath'. For example, nobody wants solrj to depend on lucene-core or lucene-spellchecker, but i can easily add new SpellChecker() to solrj java files and all tests pass. * the lack of separation (e.g core/lib and solrj/lib), makes packaging a mystery: i dont even know what packaging magic makes the solrj-lib in the binary distribution. But whatever it is probably error-prone (SOLR-3374) * the webapp/ is confusing to me: if solr core doesn't actually depend on jetty and can even work embedded, then why does it have classes that include/extend jetty/servlet classes? Shouldn't all this stuff be in webapp/ to cleanly separate it out? * the example/ in my opinion should also be treated as another 'module' and the 'example tests' should sit underneath it. I think its confusing how other tests reach around to the example. I think these are generally unrelated to your patch: but trying to do what you want with logging jars just puts it over the edge in complexity. If things like alternative logging frameworks and servlet containers are actually intended to be supported, then shouldn't we: # fix all these classpaths to be per-module, enforcing that our dependencies are what we think they are, and that we package up what we think we are packaging up. # add things like alternative ivy configurations to allow us to test these different implementations (e.g. log4j, tomcat, etc) at least in hudson via -D switches, otherwise how do we know they actually work without manual testing? Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3375) Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
-
Key: SOLR-3375
URL: https://issues.apache.org/jira/browse/SOLR-3375
Project: Solr
Issue Type: Bug
Components: clients - java
Affects Versions: 3.6, 4.0, 3.6.1
Reporter: Roger Håkansson
I've written an application which sends PDF files to Solr for indexing, but I
also need to index some meta-data which isn't contained inside the PDF.
I recently upgraded to 3.6.0 and when recompiling my app, I got some deprecated
messages which mainly was to switch from CommonsHttpSolrServer to
HttpSolrServer.
The problem I've noticed since doing this, is that all extra fields which I add
is sent to the Solr server as ASCII only, i.e UTF-8/ISO-8859-1 doesn't matter,
anything above char 127 is sent as '?'. This was not the behaviour of
CommonsHttpSolrServer.
I've tracked it down to a line (271 in 3.6.0) in HttpSolrServer.java which is:
entity.addPart(name, new StringBody(value));
The problem is that StringBody(String text) maps to
StringBody(text, text/plain, null);
and in
StringBody(String text, String mimeType, Charset charset)
we have this piece of code:
if (charset == null) {
charset = Charset.forName(US-ASCII);
}
this.content = text.getBytes(charset.name());
this.charset = charset;
So unless charset is set everything is converted to US-ASCII.
On the other hand, in CommonsHttpSolrServer.java (line 310 in 3.6.0) there is
this line
parts.add(new StringPart(p, v, UTF-8));
which adds everything as UTF-8.
The simple solution would be to change the faulty line in HttpSolrServer.java to
entity.addPart(name, new StringBody(value,Charset.forName(UTF-8)));
However, this doesn't work either since my tests have shown that neither Jetty
or Tomcat recognizes the strings as UTF-8 but interprets them as 8-bit (8859-1
I guess).
So changing HttpSolrServer.java to
entity.addPart(name, new StringBody(value,Charset.forName(ISO-8859-1)));
actually gives me the same result as using CommonsHttpSolrServer.
But my investigations have shown that there is a difference in how
Commons-HttpClient and HttpClient-4.x works.
Commons-HttpClient sends all parameters as regular POST parameters but
URLEncoded (/update/extract?param1=valueparam2=value2) while
HttpClient-4.x sends them as multipart/form-data messages and I think that the
problem is that each multipart-message should have its own charset parameter.
I.e HttpClient-4.x sends
---
--jNljZ3jE1sHG529HrzSjZWYEad-6Wu
Content-Disposition: form-data; name=literal.string_txt
åäö
---
But it should probably send something like this
---
--jNljZ3jE1sHG529HrzSjZWYEad-6Wu
Content-Disposition: form-data; name=literal.string_txt
Content-Type: text/plain; charset=utf-8
åäö
---
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3375) Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
[
https://issues.apache.org/jira/browse/SOLR-3375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Roger Håkansson updated SOLR-3375:
--
Attachment: SolrTest.java
Test program to show the problem.
Pass a URL to a Solr server as first arg and a PDF file as second.
Then search for id 1234567890 and 1234567891 and see the difference in
string_txt/string2_txt between the documents
Charset problem using HttpSolrServer instead of CommonsHttpSolrServer
-
Key: SOLR-3375
URL: https://issues.apache.org/jira/browse/SOLR-3375
Project: Solr
Issue Type: Bug
Components: clients - java
Affects Versions: 3.6, 4.0, 3.6.1
Reporter: Roger Håkansson
Attachments: SolrTest.java
I've written an application which sends PDF files to Solr for indexing, but I
also need to index some meta-data which isn't contained inside the PDF.
I recently upgraded to 3.6.0 and when recompiling my app, I got some
deprecated messages which mainly was to switch from CommonsHttpSolrServer to
HttpSolrServer.
The problem I've noticed since doing this, is that all extra fields which I
add is sent to the Solr server as ASCII only, i.e UTF-8/ISO-8859-1 doesn't
matter, anything above char 127 is sent as '?'. This was not the behaviour of
CommonsHttpSolrServer.
I've tracked it down to a line (271 in 3.6.0) in HttpSolrServer.java which is:
entity.addPart(name, new StringBody(value));
The problem is that StringBody(String text) maps to
StringBody(text, text/plain, null);
and in
StringBody(String text, String mimeType, Charset charset)
we have this piece of code:
if (charset == null) {
charset = Charset.forName(US-ASCII);
}
this.content = text.getBytes(charset.name());
this.charset = charset;
So unless charset is set everything is converted to US-ASCII.
On the other hand, in CommonsHttpSolrServer.java (line 310 in 3.6.0) there is
this line
parts.add(new StringPart(p, v, UTF-8));
which adds everything as UTF-8.
The simple solution would be to change the faulty line in HttpSolrServer.java
to
entity.addPart(name, new StringBody(value,Charset.forName(UTF-8)));
However, this doesn't work either since my tests have shown that neither
Jetty or Tomcat recognizes the strings as UTF-8 but interprets them as 8-bit
(8859-1 I guess).
So changing HttpSolrServer.java to
entity.addPart(name, new StringBody(value,Charset.forName(ISO-8859-1)));
actually gives me the same result as using CommonsHttpSolrServer.
But my investigations have shown that there is a difference in how
Commons-HttpClient and HttpClient-4.x works.
Commons-HttpClient sends all parameters as regular POST parameters but
URLEncoded (/update/extract?param1=valueparam2=value2) while
HttpClient-4.x sends them as multipart/form-data messages and I think that
the problem is that each multipart-message should have its own charset
parameter.
I.e HttpClient-4.x sends
---
--jNljZ3jE1sHG529HrzSjZWYEad-6Wu
Content-Disposition: form-data; name=literal.string_txt
åäö
---
But it should probably send something like this
---
--jNljZ3jE1sHG529HrzSjZWYEad-6Wu
Content-Disposition: form-data; name=literal.string_txt
Content-Type: text/plain; charset=utf-8
åäö
---
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256845#comment-13256845 ] Uwe Schindler commented on SOLR-3358: - Hi, I strongly agree here with Robert, one thing to add: Maven (sorry) has the notion of runtime, test and compile (and even test-compile) classpaths, which may all be different. Log4J is not the only problem that we have on that, since the upgrade to Jetty 8 we have a *serious* flaw here, too: I just repeat that on every issue because it seems nobody takes care or maybe nobody understands the problem: The Solr webapp / Solr core should be compatible with a lot of servlet containers. All on-the-market stable servlet containers are build on servlet-api 2.4 or 2.5. For compiling Solr-webapp, this API is enough and we *must* test and compile *against* and *only against* servlet-api-2.4 (like we did with Java 5 in LuSolr 3.x). If we then run tests with Jetty 8, we must of course plug in the Jetty-provided servlet-api (which is 3.0), but for compile we *must* use the *generic _original_* servlet-api-2.4 interfaces JAR file from Sun Microsystems (not a Jetty or Tomcat fake). For compiling Solr *Core*, we should only have the slf4j-api.jar file in classpath, no impls or delegators! No log4j, no commons-logging. To compile those extra addons loaded by reflection, we can use a separate compilation unit only containing the appender/listerners for various logging systems compiled solely against its own oficially provided JAR file (not e.g. log4j-over-sfl4j.jar, whcih is a fake like mentioned above). My proposal: - We should separate the lib folder to handle compile time-only references and runtime/tests execution. The runtime classpatch is also packaged into WAR file. - As Robert suggests: More clear separation into modules, so Solr core does not need jetty/servlet classes to compile or even run! - Only use *original* interface JARs on the minimum required version (servlet 2.4), from the official provider (servlet-api 2.4 from Sun Microsystems, log4j from Apache,...) while _compiling_ (like using Java 5 rt.jar in Lucene 3.x), to ensure compatibility with public APIs. Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[
https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256852#comment-13256852
]
Robert Muir commented on SOLR-3358:
---
{quote}
I strongly agree here with Robert, one thing to add: Maven (sorry) has the
notion of runtime, test and compile (and even test-compile) classpaths,
which may all be different.
{quote}
The parallel exists in ivy, its easy to use. its called configurations (we
actually already use these), and you can
name them whatever you want.
with such configurations we could even have things like test-classpath-jetty,
test-classpath-tomcat, test-classpath-log4j, whatever whatever.
We already use configurations (for a different purpose) in some of the solr
ivy.xml's...
If we wanted, i'm sure such a thing could be used to even e.g. implement
lucene's test-backwards and things like that
in the future. This is really a similar situation in many ways if you think
about it...
Capture Logging Events from JUL and Log4j
-
Key: SOLR-3358
URL: https://issues.apache.org/jira/browse/SOLR-3358
Project: Solr
Issue Type: New Feature
Reporter: Ryan McKinley
Assignee: Ryan McKinley
Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch,
SOLR-3358-logging.patch
The UI should be able to show the last few log messages. To support this, we
will need to register an Appender (log4j) or Handler
(JUL) and keep a buffer of recent log events.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[QueryParser] Omit escaped special characters
Hi, guys. Why is it OK for the QueryParser to omit escaped special chars? Or isn't it? What I'm trying to say is that the escaped char is replaced with whitespace instead of being literally passed. I try to understand why this happens. Is it because of the Analyzer or because of the Parser? Here are some tests using StandardAnalyzer and QueryParser (trunk version) to illustrate: f:foo-bar -- f:foo f:bar f:foo-bar -- f:foo bar f:foo\-bar -- f:foo bar f:foo\+bar -- f:foo bar f:foo\!bar -- f:foo bar temp:70 -- temp:70 temp:\-70 -- temp:70 temp:-70 -- temp:70 \(1\+1\)\:2 -- defaultfield:1 defaultfield:1 defaultfield:2 \(1\+1\)\:2 -- defaultfield:1 1 2 This (not sure if) issue is somehow related to LUCENE-2916 [1] [1] https://issues.apache.org/jira/browse/LUCENE-2916 Thanks, Iulius
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256860#comment-13256860 ] Ryan McKinley commented on SOLR-3358: - yes, solr classpath is a disaster! I agree with everything you say/suggest, i figured this was the tradeoff for avoiding maven The other thing to consider is a test classpath -- the only class that uses jetty in the src tree is JettySolrRunner. I think that could be moved to test. re SpellChecker in solrj. The maven build should fail if you do this since it does use different classpaths for each module. (not a real solution, but just pointing it out) As a first step, I think we should remove the single solr/lib folder and replace it with: solrj/lib core/lib core/lib-test (includes jetty) webapp/lib (has the slf4j-over stuff) Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256863#comment-13256863 ] Ryan McKinley commented on SOLR-3358: - bq. For compiling Solr-webapp, this API is enough and we must test and compile against and only against servlet-api-2.4 FWIW, the maven build uses 2.4 so we would get a jenkins failure if we use something 3.0 specific if we had different lib/classpath for core/lib-test and example/lib we could use jetty-7 in core/lib-test and jetty-8 in example/lib -- this would let us test both jetty 7 and 8 Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256867#comment-13256867 ] Yonik Seeley commented on SOLR-3358: Trying to support different servlet containers, different logging frameworks, etc, is a mess... IMO, we should be considering Solr more as a server (and the fact that it uses Jetty and Java logging an implementation detail). I don't think making everything pluggable buys us much but a lot of headaches. Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256877#comment-13256877 ] Robert Muir commented on SOLR-3358: --- Well for one the current structure is really unrelated to maven. When Steve Rowe and I first started working on the build, there were other things to fix (core tests depended on contribs, etc). So i think its improving, I'm not trying to complain: if we could have fixed this stuff safely when transitioning to ivy, we would have. I feel like Chris Male and I spent an entire night trying to figure out the best approach: populating the huge lib/ folder just like before simple kept the issue scope contained. Just a few notes about this: # we don't really need to be downloading jars and putting them in lib/ at all (LUCENE-3943). what we have now is a 'transition mechanism' that works like the old build, but we should really fix this: then people wont have issues with things like having stale jars or anything else: and we avoid copying around or whatever. Still lets put this aside, we can still improve things right now (see below) # i agree with your suggestions, though i think we actually have jetty-test classes in test-framework? so i think it should be solrj/lib, core/lib, test-framework/lib, etc (don't try to tackle the lib-test initially, i think we should attack 'separation' first). # after accomplishing #2 above, we can then start to think about alternative configurations, and whether or not we even want to try to do that before fixing #1. Fixing #1 would make this task much simpler and cleaner. i don't think we should have a separate lib/ with jetty7 and example with jetty8, because i think we would ultimately want the flexibility to be able to run both core and example tests with any of (jetty6, jetty7, jetty8, tomcat-xx, ...), and this could be specified with a -D or something. Perhaps the defaults are set to something like you suggest, but hudson could test other possibilities. Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256878#comment-13256878 ] Mark Miller commented on SOLR-3358: --- Yup - by having nothing out of the box and trying to support everything you just ensure you support everything poorly. We should pick a framework and give good out of the box logging. We are a search server first, not a lib. I think our current logging situation is in the stone age. Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3358) Capture Logging Events from JUL and Log4j
[ https://issues.apache.org/jira/browse/SOLR-3358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256885#comment-13256885 ] Robert Muir commented on SOLR-3358: --- Regardless of how you feel about whether or not we support the different containers, whether solr should be modular or monolithic, the classpath for solrj etc is still totally wrong. You can make it depend on anything in solr/lib (e.g. as i said put a SpellChecker or IndexWriter in a solrj class), and all tests pass. In fact, I can go find at least 2 situations (one caused by me, the other by merging SolrCloud) where this actually happened that solrj depended on lucene. Only manual inspection finds this out, but tests should really fail. Besides the lack of no enforcement that solrj should only depend on certain things, there is no simple solrj/lib folder for packaging solrj-lib (instead some error-prone inclusions/exclusions) Capture Logging Events from JUL and Log4j - Key: SOLR-3358 URL: https://issues.apache.org/jira/browse/SOLR-3358 Project: Solr Issue Type: New Feature Reporter: Ryan McKinley Assignee: Ryan McKinley Attachments: SOLR-3358-compile-path.patch, SOLR-3358-logging.patch, SOLR-3358-logging.patch The UI should be able to show the last few log messages. To support this, we will need to register an Appender (log4j) or Handler (JUL) and keep a buffer of recent log events. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3996) website System Requirements links to raw page
[ https://issues.apache.org/jira/browse/LUCENE-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256892#comment-13256892 ] Robert Muir commented on LUCENE-3996: - With the cms back up, it went to staging (http://lucene.staging.apache.org/core/systemreqs.html) and looks nice! But then i pushed that to production, and it comes out as a 404 (http://lucene.apache.org/core/systemreqs.html) Im gonna try one more time before throwing in the towel. website System Requirements links to raw page --- Key: LUCENE-3996 URL: https://issues.apache.org/jira/browse/LUCENE-3996 Project: Lucene - Java Issue Type: Bug Reporter: selckin Sorry if this is the wrong place to report this, The System Requirements link on the right @ http://lucene.apache.org/core/documentation.html, link to a raw page without the header menus etc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3996) website System Requirements links to raw page
[ https://issues.apache.org/jira/browse/LUCENE-3996?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-3996. - Resolution: Fixed Got it going... thanks selckin! ... now i notice there is a broken link to a trunk location, i'll take care of that too website System Requirements links to raw page --- Key: LUCENE-3996 URL: https://issues.apache.org/jira/browse/LUCENE-3996 Project: Lucene - Java Issue Type: Bug Reporter: selckin Sorry if this is the wrong place to report this, The System Requirements link on the right @ http://lucene.apache.org/core/documentation.html, link to a raw page without the header menus etc -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-tests-only-trunk - Build # 13260 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-tests-only-trunk/13260/ No tests ran. Build Log (for compile errors): [...truncated 5260 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3997) join module should not depend on grouping module
[ https://issues.apache.org/jira/browse/LUCENE-3997?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256931#comment-13256931 ] Martijn van Groningen commented on LUCENE-3997: --- I also think we can move these classes to core. These are small classes and we can mark these classes as experimental. Maybe we can even make this classes 'lighter' by only moving the public methods to core (maybe as interface?). E.g. ValueSource would have all the public methods in core and a BaseValueSource (Or AbstractValueSource) in the queries module that contains ValueSourceComparatorSource and ValueSourceComparator. Just an idea. I'll create a new issue to not make grouping module depend on the queries module. join module should not depend on grouping module Key: LUCENE-3997 URL: https://issues.apache.org/jira/browse/LUCENE-3997 Project: Lucene - Java Issue Type: Task Affects Versions: 4.0 Reporter: Robert Muir Fix For: 4.0 Attachments: LUCENE-3997.patch, LUCENE-3997.patch I think TopGroups/GroupDocs should simply be in core? Both grouping and join modules use these trivial classes, but join depends on grouping just for them. I think its better that we try to minimize these inter-module dependencies. Of course, another option is to combine grouping and join into one module, but last time i brought that up nobody could agree on a name. Anyway I think the change is pretty clean: its similar to having basic stuff like Analyzer.java in core, so other things can work with Analyzer without depending on any specific implementing modules. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3369) shards.tolerant=true broken on group and facet queries
[ https://issues.apache.org/jira/browse/SOLR-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13256963#comment-13256963 ] Martijn van Groningen commented on SOLR-3369: - I took a quick look. Patch also seems to add support for adding shards.info parameter for grouping and adds exception information to the response when a shard request fails. I don't that think that shards.tolerant is a supported feature in Solr 3.x versions (I couldn't find any reference of this param in the 3.6 source). So I think we shouldn't add this to the 3.6 branch since that would be adding a new feature to a Solr version that is actually in maintenance mode. shards.tolerant=true broken on group and facet queries -- Key: SOLR-3369 URL: https://issues.apache.org/jira/browse/SOLR-3369 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0, 3.6.1 Environment: Distributed environment (shards) Reporter: Russell Black Labels: patch Attachments: SOLR-3369-shards-tolerant-3_6.patch, SOLR-3369-shards-tolerant.patch In a distributed environment, shards.tolerant=true allows for partial results to be returned when individual shards are down. For group=true and facet=true queries, using this feature results in an error when shards are down. This patch allows users to use the shard tolerance feature with facet and grouping queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3178) Versioning - optimistic locking
[ https://issues.apache.org/jira/browse/SOLR-3178?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257004#comment-13257004 ] Yonik Seeley commented on SOLR-3178: FYI, I've got a patch that seems to work fine... I'm just still finishing up some of the tests. Versioning - optimistic locking --- Key: SOLR-3178 URL: https://issues.apache.org/jira/browse/SOLR-3178 Project: Solr Issue Type: New Feature Components: update Affects Versions: 3.5 Environment: All Reporter: Per Steffensen Assignee: Per Steffensen Labels: RDBMS, insert, locking, nosql, optimistic, uniqueKey, update, versioning Fix For: 4.0 Original Estimate: 168h Remaining Estimate: 168h In order increase the ability of Solr to be used as a NoSql database (lots of concurrent inserts, updates, deletes and queries in the entire lifetime of the index) instead of just a search index (first: everything indexed (in one thread), after: only queries), I would like Solr to support versioning to be used for optimistic locking. When my intent (see SOLR-3173) is to update an existing document, I will need to provide a version-number equal to the version number I got when I fetched the existing document for update plus one. If this provided version-number does not correspond to the newest version-number of that document at the time of update plus one, I will get a VersionConflict error. If it does correspond the document will be updated with the new one, so that the newest version-number of that document is NOW one higher than before the update. Correct but efficient concurrency handling. When my intent (see SOLR-3173) is to insert a new document, the version number provided will not be used - instead a version-number 0 will be used. According to SOLR-3173 insert will only succeed if a document with the same value on uniqueKey-field does not already exist. In general when talking about different versions of the same document, of course we need to be able to identify when a document is the same - that, per definition, is when the values of the uniqueKey-fields are equal. The functionality provided by this issue is only really meaningfull when you run with updateLog activated. This issue might be solved more or less at the same time as SOLR-3173, and only one single SVN patch might be given to cover both issues. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Problem running all of a module's tests under IntelliJ: Wrong test finished.
Ok, glad it worked. I'm wondering if anybody is using netbeans?... :) Dawid On Wed, Apr 18, 2012 at 7:58 PM, Steven A Rowe sar...@syr.edu wrote: All modules' tests run (and succeed) for me now (after hacking the Solr library to exclude log4j-over-slf4j by explicitly listing all jars except l-over-s under solr/lib/). Thanks again! - Steve -Original Message- From: Steven A Rowe [mailto:sar...@syr.edu] Sent: Wednesday, April 18, 2012 1:30 PM To: dev@lucene.apache.org Subject: RE: Problem running all of a module's tests under IntelliJ: Wrong test finished. Yes! analyzers-common module tests all run now (they didn't before your LUCENE-3993 commit); I'm running all of the others now. Thanks, Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Wednesday, April 18, 2012 12:00 PM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. Hi Steve, I think it should be all right now (checked on simple examples, didn't run full lucene suites). Let me know if this works for you. Dawid P.S. It's a long story why this was happening -- different assumptions by vendors concerning events passed to RunListeners... On Wed, Apr 18, 2012 at 2:08 PM, Steven A Rowe sar...@syr.edu wrote: Cool, thanks! -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Wednesday, April 18, 2012 7:44 AM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. I think I know what the problem is and I'm working on a fix. This may require you to set a property strictJunitCompatibilityIsStupid though... I'm not really keen on making what I consider flaws in JUnit a default behavior :) Dawid On Wed, Apr 18, 2012 at 12:05 AM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: Thanks Steve, I'll be bulk-fixing all the discovered issues tomorrow. I'll let you know if I figure out what's causing this. Dawid On Wed, Apr 18, 2012 at 12:00 AM, Steven A Rowe sar...@syr.edu wrote: Dawid, I have included in the IntelliJ IDEA configuration for Lucene/Solr a set of run configurations, one per module, that runs all tests in each module. After you have run ant idea at the top level, then opened the project in IntelliJ IDEA, then set up the JDK to use (the menu path to set up the JDK is printed to the terminal after you run ant idea) you should be able to see something similar to this: http://postimage.org/image/ivi5srd5v To the left of the triangular green arrow icon (which means: run the selected run configuration), there is a dropdown menu for run configurations. In the above-linked image, I've left-clicked on this dropdown, and the mouse is hovering over Module analyzers-common - this is one of the modules that exhibits the test running problem. Left-click on Module analyzers-common to set the active run configuration. After you do this, the run configuration dropdown will change to display this label. Then you can start the tests associated with this by clicking on the green triangular button to the right of the run configuration dropdown. When IntelliJ runs tests, it will first make the associated module and its dependent modules, then show a JUnit pane at the bottom of the window, with a tree of test suites and their tests on the left, and console output on the right. Let me know if you need more info. Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Tuesday, April 17, 2012 5:26 PM To: dev@lucene.apache.org Subject: Re: Problem running all of a module's tests under IntelliJ: Wrong test finished. Steven can you send me a screenshot or something showing where I should click to get this failure? :) Dawid On Tue, Apr 17, 2012 at 6:04 PM, Steven A Rowe sar...@syr.edu wrote: Hi Dawid :) Do you use IntelliJ? There appears to be some form of bad interaction between the new RandomizedTesting library additions and IntelliJ's test runner. When I try to run all of an IntelliJ module's tests under IntelliJ, e.g. analyzers-common or lucene (including core and test-framework), not all tests run; those that don't run are reported as not started. The external test process reports Wrong test finished. (???) and then returns exit code -1. This behavior is relatively new - I don't think the modules/*-lucene/ move is the culprit (the IntelliJ lucene+test-framework module didn't move and it has this issue). Here's the output from running all analyzers-common tests: -- C:\Program Files\Java\jdk1.6.0_21\bin\java -ea -DtempDir=temp -Didea.launcher.port=7541 -Didea.launcher.bin.path=C:\Program Files (x86)\JetBrains\IntelliJ IDEA 11.1\bin -Dfile.encoding=UTF-8 -classpath
[jira] [Commented] (SOLR-3369) shards.tolerant=true broken on group and facet queries
[ https://issues.apache.org/jira/browse/SOLR-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13257057#comment-13257057 ] Russell Black commented on SOLR-3369: - Martijn, You're right, 3.6 doesn't have this feature. My mistake. Just use the trunk patch if you wish. The reason I had a 3.6 version of this patch is that we have backported SOLR-3134 (original shards info/tolerance feature) to 3.6. SOLR-3369-shards-tolerant-3_6.patch is intended to be applied on top of that, and is of no use without it. I just posted our SOLR-3134 backport patch if you have an interest in adding shards.info and shards.tolerant to 3.x. If not, at least the patch will be available for other 3.x users who want that feature. shards.tolerant=true broken on group and facet queries -- Key: SOLR-3369 URL: https://issues.apache.org/jira/browse/SOLR-3369 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0, 3.6.1 Environment: Distributed environment (shards) Reporter: Russell Black Labels: patch Attachments: SOLR-3369-shards-tolerant-3_6.patch, SOLR-3369-shards-tolerant.patch In a distributed environment, shards.tolerant=true allows for partial results to be returned when individual shards are down. For group=true and facet=true queries, using this feature results in an error when shards are down. This patch allows users to use the shard tolerance feature with facet and grouping queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3369) shards.tolerant=true broken on group and facet queries
[ https://issues.apache.org/jira/browse/SOLR-3369?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Russell Black updated SOLR-3369: Attachment: SOLR-3134-shard-info-3_6.patch shards.tolerant=true broken on group and facet queries -- Key: SOLR-3369 URL: https://issues.apache.org/jira/browse/SOLR-3369 Project: Solr Issue Type: Bug Components: search Affects Versions: 4.0, 3.6.1 Environment: Distributed environment (shards) Reporter: Russell Black Labels: patch Attachments: SOLR-3134-shard-info-3_6.patch, SOLR-3369-shards-tolerant-3_6.patch, SOLR-3369-shards-tolerant.patch In a distributed environment, shards.tolerant=true allows for partial results to be returned when individual shards are down. For group=true and facet=true queries, using this feature results in an error when shards are down. This patch allows users to use the shard tolerance feature with facet and grouping queries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
