[jira] [Created] (SOLR-3789) Cannot use internal compression in replication handler
Sami Siren created SOLR-3789: Summary: Cannot use internal compression in replication handler Key: SOLR-3789 URL: https://issues.apache.org/jira/browse/SOLR-3789 Project: Solr Issue Type: Bug Affects Versions: 4.0-BETA Reporter: Sami Siren Fix For: 4.0 The implementation for internal compression is currently broken. a Wrong parameter value is used to activate the feature in SnapPuller. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3789) Cannot use internal compression in replication handler
[ https://issues.apache.org/jira/browse/SOLR-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren updated SOLR-3789: - Attachment: SOLR-3789.patch fix + improvement to the testcase so that it randomly toggles compression between internal/off Cannot use internal compression in replication handler Key: SOLR-3789 URL: https://issues.apache.org/jira/browse/SOLR-3789 Project: Solr Issue Type: Bug Affects Versions: 4.0-BETA Reporter: Sami Siren Fix For: 4.0 Attachments: SOLR-3789.patch The implementation for internal compression is currently broken. a Wrong parameter value is used to activate the feature in SnapPuller. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4332) Integrate PiTest mutation coverage tool into build
[
https://issues.apache.org/jira/browse/LUCENE-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448527#comment-13448527
]
Uwe Schindler commented on LUCENE-4332:
---
{code}
permission java.security.SecurityPermission *, read,write;
{code}
This makes no sense, as SecurityPermission has no action, so read,write
should be ignored. I was restricting SecurityPermission with something in mind
(see the last 2 lines that allowed only the BouncyCastle installed by TIKA -
now everything is allowed). What fails if I remove that line? I have no time to
run the whole pitest suite
bq. rather than as a full force prevention of malicious code
The idea was to find places (especially in TIKA) that do things they should not
do (like enabling security providers), which makes the configuration of J2EE
container hosting Solr hard. So we should limit all this, to see when somebody
adds a new feature to Solr that needs additional permissions.
I already working on restricting RuntimePermission at all, so only things
like reflection and property access is allowed.
Integrate PiTest mutation coverage tool into build
--
Key: LUCENE-4332
URL: https://issues.apache.org/jira/browse/LUCENE-4332
Project: Lucene - Core
Issue Type: Improvement
Affects Versions: 4.1, 5.0
Reporter: Greg Bowyer
Assignee: Greg Bowyer
Labels: build
Attachments:
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch
As discussed briefly on the mailing list, this patch is an attempt to
integrate the PiTest mutation coverage tool into the lucene build
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-4332) Integrate PiTest mutation coverage tool into build
[
https://issues.apache.org/jira/browse/LUCENE-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448527#comment-13448527
]
Uwe Schindler edited comment on LUCENE-4332 at 9/5/12 5:58 PM:
---
{code}
permission java.security.SecurityPermission *, read,write;
{code}
This makes no sense, as SecurityPermission has no action, so read,write
should be ignored. I was restricting SecurityPermission with something in mind
(see the last 2 lines that allowed only the BouncyCastle installed by TIKA -
now everything is allowed). What fails if I remove that line? I have no time to
run the whole pitest suite
bq. rather than as a full force prevention of malicious code
The idea was to find places (especially in TIKA) that do things they should not
do (like enabling security providers), which makes the configuration of J2EE
container hosting Solr hard. So we should limit all this, to see when somebody
adds a new feature to Solr that needs additional permissions.
I am already working on restricting RuntimePermission more, so only things
like reflection and property access is allowed.
was (Author: thetaphi):
{code}
permission java.security.SecurityPermission *, read,write;
{code}
This makes no sense, as SecurityPermission has no action, so read,write
should be ignored. I was restricting SecurityPermission with something in mind
(see the last 2 lines that allowed only the BouncyCastle installed by TIKA -
now everything is allowed). What fails if I remove that line? I have no time to
run the whole pitest suite
bq. rather than as a full force prevention of malicious code
The idea was to find places (especially in TIKA) that do things they should not
do (like enabling security providers), which makes the configuration of J2EE
container hosting Solr hard. So we should limit all this, to see when somebody
adds a new feature to Solr that needs additional permissions.
I already working on restricting RuntimePermission at all, so only things
like reflection and property access is allowed.
Integrate PiTest mutation coverage tool into build
--
Key: LUCENE-4332
URL: https://issues.apache.org/jira/browse/LUCENE-4332
Project: Lucene - Core
Issue Type: Improvement
Affects Versions: 4.1, 5.0
Reporter: Greg Bowyer
Assignee: Greg Bowyer
Labels: build
Attachments:
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch
As discussed briefly on the mailing list, this patch is an attempt to
integrate the PiTest mutation coverage tool into the lucene build
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4354: -- Attachment: (was: LUCENE-4354.patch) add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4332) Integrate PiTest mutation coverage tool into build
[
https://issues.apache.org/jira/browse/LUCENE-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448541#comment-13448541
]
Greg Bowyer commented on LUCENE-4332:
-
{quote}
permission java.security.SecurityPermission *, read,write;
This makes no sense, as SecurityPermission has no action, so read,write
should be ignored. I was restricting SecurityPermission with something in mind
(see the last 2 lines that allowed only the BouncyCastle installed by TIKA -
now everything is allowed). What fails if I remove that line? I have no time to
run the whole pitest suite
{quote}
You are right on that, I will change it
{quote}
The idea was to find places (especially in TIKA) that do things they should not
do (like enabling security providers), which makes the configuration of J2EE
container hosting Solr hard. So we should limit all this, to see when somebody
adds a new feature to Solr that needs additional permissions.
I am already working on restricting RuntimePermission more, so only things
like reflection and property access is allowed.
{quote}
Ok the intention changed a fair bit, I was still under the impression that we
were targeting making this keep tests in a sandbox rather than helping solr
with hosting inside complex J2EE arrangements
Integrate PiTest mutation coverage tool into build
--
Key: LUCENE-4332
URL: https://issues.apache.org/jira/browse/LUCENE-4332
Project: Lucene - Core
Issue Type: Improvement
Affects Versions: 4.1, 5.0
Reporter: Greg Bowyer
Assignee: Greg Bowyer
Labels: build
Attachments:
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch
As discussed briefly on the mailing list, this patch is an attempt to
integrate the PiTest mutation coverage tool into the lucene build
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448546#comment-13448546 ] Uwe Schindler commented on LUCENE-4354: --- Robert: I accidentally deleted your latest patch (I got confused with the order of patches). Can you reattach? add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [jira] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies
This was unwanted; I tried to understand what patches are there... :( - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Uwe Schindler (JIRA) [mailto:j...@apache.org] Sent: Wednesday, September 05, 2012 9:06 AM To: dev@lucene.apache.org Subject: [jira] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies [ https://issues.apache.org/jira/browse/LUCENE- 4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4354: -- Attachment: (was: LUCENE-4354.patch) add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-3789) Cannot use internal compression in replication handler
[ https://issues.apache.org/jira/browse/SOLR-3789?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Sami Siren resolved SOLR-3789. -- Resolution: Fixed committed. trunk: r1381043 4x: 1381045 Cannot use internal compression in replication handler Key: SOLR-3789 URL: https://issues.apache.org/jira/browse/SOLR-3789 Project: Solr Issue Type: Bug Affects Versions: 4.0-BETA Reporter: Sami Siren Fix For: 4.0 Attachments: SOLR-3789.patch The implementation for internal compression is currently broken. a Wrong parameter value is used to activate the feature in SnapPuller. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4332) Integrate PiTest mutation coverage tool into build
[
https://issues.apache.org/jira/browse/LUCENE-4332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448556#comment-13448556
]
Greg Bowyer commented on LUCENE-4332:
-
Ok the security permission stuff is tightened up for just the internal jvm cache
basically it is as follows
{code}
// Needed for some things in DNS caching in the JVM
permission java.security.SecurityPermission
getProperty.networkaddress.cache.ttl;
permission java.security.SecurityPermission
getProperty.networkaddress.cache.negative.ttl;
{code}
branch_4x
Sendinglucene/tools/junit4/tests.policy
Transmitting file data .
Committed revision 1381046.
trunk
Sendinglucene/tools/junit4/tests.policy
Transmitting file data .
Committed revision 1381047.
greg@gregslaptop ~/project
Integrate PiTest mutation coverage tool into build
--
Key: LUCENE-4332
URL: https://issues.apache.org/jira/browse/LUCENE-4332
Project: Lucene - Core
Issue Type: Improvement
Affects Versions: 4.1, 5.0
Reporter: Greg Bowyer
Assignee: Greg Bowyer
Labels: build
Attachments:
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch,
LUCENE-4332-Integrate-PiTest-mutation-coverage-tool-into-build.patch
As discussed briefly on the mailing list, this patch is an attempt to
integrate the PiTest mutation coverage tool into the lucene build
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3784) Schema-Browser hangs because of similarity
[
https://issues.apache.org/jira/browse/SOLR-3784?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448566#comment-13448566
]
Stefan Matheis (steffkes) commented on SOLR-3784:
-
Sorry Greg, perhaps i was not clear enough .. the attached patch is only a
suggestion, because i'm not sure if this change does handle all possible cases
- so please review it and extend/change if needed .. otherwise it's fine :)
bq. Humm why does this only trigger for type int ?
type=int was only an example. Have a look at
{{/solr/collection1/admin/luke?show=schemawt=json}} - all defined fields with
_similarity: {}_ will have the same behaviour
Schema-Browser hangs because of similarity
--
Key: SOLR-3784
URL: https://issues.apache.org/jira/browse/SOLR-3784
Project: Solr
Issue Type: Bug
Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Greg Bowyer
Attachments: SOLR-3784.patch
Opening the Schema-Browser with the Default Configuration, switching the
selection to type=int throws an error:
{code}Uncaught TypeError: Cannot call method 'esc' of undefined //
schema-browser.js:893{code}
On the first Look, this was introduced by SOLR-3572 .. right?
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4360) Support running the same test suite multiple times in parallel
[
https://issues.apache.org/jira/browse/LUCENE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448571#comment-13448571
]
Dawid Weiss commented on LUCENE-4360:
-
Any ideas what to call this parameter? It's not the same as tests.iters because
it multiplies entire suites. I came up with:
{code}
-Dtests.multiply
-Dtests.duplicate
or the short equivalents:
-Dtests.mply
-Dtests.dups
{code}
Support running the same test suite multiple times in parallel
--
Key: LUCENE-4360
URL: https://issues.apache.org/jira/browse/LUCENE-4360
Project: Lucene - Core
Issue Type: New Feature
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0, 4.0
Attachments: quickhack.patch
The current test execution multiplier or:
{code}
-Dtests.iters=N
{code}
generates multiple tests (method executions) under a test class (suite). All
these tests, however, are bound to a single class so they must run
sequentially and on a single JVM (because of how JUnit works -- nesting of
rules, class hooks, etc.).
Mark pointed out that if somebody has a multi-core CPU then it'd be nice to
be able to run a single suite in parallel, possibly in combination with
tests.iters (so that a single test method is executed X times on Y parallel
JVMs).
This is surprisingly easy with the randomized runner because it currently
accepts duplicate suite names and will load-balance them in a normal way.
So, if one has Y cores (JVMs) then providing a suite name X times will result
in X executions, balanced across Y JVMs.
The only problem is how to multiply suite names. This can be done in a
number of ways, starting from a custom resource collection wrapper and ending
at a built-in code in the runner itself. I think the custom collection
wrapper approach would be interesting, I'll explore this direction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3790) NullPointerException and ConcurrentModificationException thrown when searching with highlighter
shou aoki created SOLR-3790:
---
Summary: NullPointerException and ConcurrentModificationException
thrown when searching with highlighter
Key: SOLR-3790
URL: https://issues.apache.org/jira/browse/SOLR-3790
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 3.5
Environment: Ubuntu 12.04, Solr 3.5
Reporter: shou aoki
Hi, Im using Solr 3.5.
I found strange phenomenon in solr log.
This phenomenon has two exceptions that NullPointerException and
ConcurrentModificationException.
These exceptions are thrown by discrete threads.
I think, The same two queries thrown at same time because error log recorded at
same time. But I can't reproduce it.
Does anyone have the same phenomenon?
{code}
2012-08-21 00:07:49,868 [qtp979682126-953] ERROR SolrCore -
java.util.ConcurrentModificationException
at
java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:778)
at java.util.LinkedList$ListItr.next(LinkedList.java:713)
at
org.apache.solr.highlight.SolrHighlighter.getHighlightFields(SolrHighlighter.java:106)
at
org.apache.solr.util.SolrPluginUtils.optimizePreFetchDocs(SolrPluginUtils.java:259)
at
org.apache.solr.handler.component.QueryComponent.doPrefetch(QueryComponent.java:478)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:385)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
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.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:350)
at
org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:442)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:941)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:679)
2012-08-21 00:07:49,868 [qtp979682126-938] ERROR SolrCore -
java.lang.NullPointerException
at
org.apache.solr.highlight.SolrHighlighter.getHighlightFields(SolrHighlighter.java:107)
at
org.apache.solr.util.SolrPluginUtils.optimizePreFetchDocs(SolrPluginUtils.java:259)
at
org.apache.solr.handler.component.QueryComponent.doPrefetch(QueryComponent.java:478)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:385)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
at
[jira] [Updated] (SOLR-3790) NullPointerException and ConcurrentModificationException are thrown when searching with highlighter
[
https://issues.apache.org/jira/browse/SOLR-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shou aoki updated SOLR-3790:
Summary: NullPointerException and ConcurrentModificationException are
thrown when searching with highlighter (was: NullPointerException and
ConcurrentModificationException thrown when searching with highlighter)
NullPointerException and ConcurrentModificationException are thrown when
searching with highlighter
---
Key: SOLR-3790
URL: https://issues.apache.org/jira/browse/SOLR-3790
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 3.5
Environment: Ubuntu 12.04, Solr 3.5
Reporter: shou aoki
Hi, Im using Solr 3.5.
I found strange phenomenon in solr log.
This phenomenon has two exceptions that NullPointerException and
ConcurrentModificationException.
These exceptions are thrown by discrete threads.
I think, The same two queries thrown at same time because error log recorded
at same time. But I can't reproduce it.
Does anyone have the same phenomenon?
{code}
2012-08-21 00:07:49,868 [qtp979682126-953] ERROR SolrCore -
java.util.ConcurrentModificationException
at
java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:778)
at java.util.LinkedList$ListItr.next(LinkedList.java:713)
at
org.apache.solr.highlight.SolrHighlighter.getHighlightFields(SolrHighlighter.java:106)
at
org.apache.solr.util.SolrPluginUtils.optimizePreFetchDocs(SolrPluginUtils.java:259)
at
org.apache.solr.handler.component.QueryComponent.doPrefetch(QueryComponent.java:478)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:385)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
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.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:350)
at
org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:442)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:941)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at
org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:679)
2012-08-21 00:07:49,868 [qtp979682126-938] ERROR SolrCore -
java.lang.NullPointerException
at
org.apache.solr.highlight.SolrHighlighter.getHighlightFields(SolrHighlighter.java:107)
at
org.apache.solr.util.SolrPluginUtils.optimizePreFetchDocs(SolrPluginUtils.java:259)
at
org.apache.solr.handler.component.QueryComponent.doPrefetch(QueryComponent.java:478)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:385)
[jira] [Updated] (SOLR-3790) NullPointerException and ConcurrentModificationException are thrown when searching with highlighter
[
https://issues.apache.org/jira/browse/SOLR-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shou aoki updated SOLR-3790:
Description:
Hi, Im using Solr 3.5.
I found strange phenomenon in solr log.
This phenomenon has two exceptions that NullPointerException and
ConcurrentModificationException.
These exceptions are thrown by discrete threads.
I think, The same two queries thrown at same time because error log recorded at
same time. But I can't reproduce it.
Does anyone have the same phenomenon?
{code}
2012-08-21 00:07:49,868 [qtp979682126-953] ERROR SolrCore -
java.util.ConcurrentModificationException
at
java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:778)
at java.util.LinkedList$ListItr.next(LinkedList.java:713)
at
org.apache.solr.highlight.SolrHighlighter.getHighlightFields(SolrHighlighter.java:106)
at
org.apache.solr.util.SolrPluginUtils.optimizePreFetchDocs(SolrPluginUtils.java:259)
at
org.apache.solr.handler.component.QueryComponent.doPrefetch(QueryComponent.java:478)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:385)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
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.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:350)
at
org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:442)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:941)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:679)
2012-08-21 00:07:49,868 [qtp979682126-938] ERROR SolrCore -
java.lang.NullPointerException
at
org.apache.solr.highlight.SolrHighlighter.getHighlightFields(SolrHighlighter.java:107)
at
org.apache.solr.util.SolrPluginUtils.optimizePreFetchDocs(SolrPluginUtils.java:259)
at
org.apache.solr.handler.component.QueryComponent.doPrefetch(QueryComponent.java:478)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:385)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
[jira] [Updated] (SOLR-3790) NullPointerException and ConcurrentModificationException are thrown when searching with highlighter
[
https://issues.apache.org/jira/browse/SOLR-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shou aoki updated SOLR-3790:
Description:
Hi, Im using Solr 3.5.
I found strange phenomenon in solr log.
This phenomenon has two exceptions that NullPointerException and
ConcurrentModificationException.
These exceptions are thrown by discrete threads.
I think, The same two queries thrown at same time because error log recorded at
same time. But I can't reproduce it.
Does anyone have the same phenomenon?
{code}
2012-08-21 00:07:49,868 [qtp979682126-953] INFO SolrCore - [c3] webapp=/solr
path=/select params={hl.tag.post=[%02]
sort=score+deschl.tag.pre=[%01]hl.fl=*wt=javabinhl=truedefType=normalizeQParserrows=40version=2fl=score,*h
l.useFastVectorHighlighter=truestart=0q=hogefq=((ap.l:771)+AND+(*:*))}
hits=4 status=500 QTime=164
2012-08-21 00:07:49,868 [qtp979682126-938] INFO SolrCore - [c3] webapp=/solr
path=/select params={hl.tag.post=[%02]
sort=score+deschl.tag.pre=[%01]hl.fl=*wt=javabinhl=truedefType=normalizeQParserrows=12version=2fl=score,*h
l.useFastVectorHighlighter=truestart=0q=hogefq=((ap.l:771)+AND+(*:*))}
hits=4 status=500 QTime=1094
2012-08-21 00:07:49,873 [qtp979682126-953] ERROR SolrDispatchFilter -
java.util.ConcurrentModificationException
at
java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:778)
at java.util.LinkedList$ListItr.next(LinkedList.java:713)
at
org.apache.solr.highlight.SolrHighlighter.getHighlightFields(SolrHighlighter.java:106)
at
org.apache.solr.util.SolrPluginUtils.optimizePreFetchDocs(SolrPluginUtils.java:259)
at
org.apache.solr.handler.component.QueryComponent.doPrefetch(QueryComponent.java:478)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:385)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
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.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:350)
at
org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:442)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:941)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:679)
2012-08-21 00:07:49,873 [qtp979682126-938] ERROR SolrDispatchFilter -
java.lang.NullPointerException
at
org.apache.solr.highlight.SolrHighlighter.getHighlightFields(SolrHighlighter.java:107)
at
org.apache.solr.util.SolrPluginUtils.optimizePreFetchDocs(SolrPluginUtils.java:259)
at
org.apache.solr.handler.component.QueryComponent.doPrefetch(QueryComponent.java:478)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:385)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
at
[jira] [Updated] (SOLR-3790) NullPointerException and ConcurrentModificationException are thrown when searching with highlighter
[
https://issues.apache.org/jira/browse/SOLR-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
shou aoki updated SOLR-3790:
Description:
Hi, Im using Solr 3.5.
I found strange phenomenon in solr log.
This phenomenon has two exceptions that NullPointerException and
ConcurrentModificationException.
These exceptions are thrown by discrete threads.
I think, The same two queries thrown at same time because error log recorded at
same time. But I can't reproduce it.
Does anyone have the same phenomenon?
{code}
2012-08-21 00:07:49,868 [qtp979682126-953] INFO SolrCore - [c3] webapp=/solr
path=/select
params={hl.tag.post=[%02]sort=score+deschl.tag.pre=[%01]hl.fl=*wt=javabinhl=truedefType=normalizeQParserrows=40version=2fl=score,*hl.useFastVectorHighlighter=truestart=0q=hogefq=((ap.l:771)+AND+(*:*))}
hits=4 status=500 QTime=164
2012-08-21 00:07:49,868 [qtp979682126-938] INFO SolrCore - [c3] webapp=/solr
path=/select
params={hl.tag.post=[%02]sort=score+deschl.tag.pre=[%01]hl.fl=*wt=javabinhl=truedefType=normalizeQParserrows=12version=2fl=score,*hl.useFastVectorHighlighter=truestart=0q=hogefq=((ap.l:771)+AND+(*:*))}
hits=4 status=500 QTime=1094
2012-08-21 00:07:49,873 [qtp979682126-953] ERROR SolrDispatchFilter -
java.util.ConcurrentModificationException
at
java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:778)
at java.util.LinkedList$ListItr.next(LinkedList.java:713)
at
org.apache.solr.highlight.SolrHighlighter.getHighlightFields(SolrHighlighter.java:106)
at
org.apache.solr.util.SolrPluginUtils.optimizePreFetchDocs(SolrPluginUtils.java:259)
at
org.apache.solr.handler.component.QueryComponent.doPrefetch(QueryComponent.java:478)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:385)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
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.HandlerWrapper.handle(HandlerWrapper.java:110)
at org.eclipse.jetty.server.Server.handle(Server.java:350)
at
org.eclipse.jetty.server.HttpConnection.handleRequest(HttpConnection.java:442)
at
org.eclipse.jetty.server.HttpConnection$RequestHandler.content(HttpConnection.java:941)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:801)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:224)
at
org.eclipse.jetty.server.AsyncHttpConnection.handle(AsyncHttpConnection.java:51)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint.handle(SelectChannelEndPoint.java:586)
at
org.eclipse.jetty.io.nio.SelectChannelEndPoint$1.run(SelectChannelEndPoint.java:44)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:598)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:533)
at java.lang.Thread.run(Thread.java:679)
2012-08-21 00:07:49,873 [qtp979682126-938] ERROR SolrDispatchFilter -
java.lang.NullPointerException
at
org.apache.solr.highlight.SolrHighlighter.getHighlightFields(SolrHighlighter.java:107)
at
org.apache.solr.util.SolrPluginUtils.optimizePreFetchDocs(SolrPluginUtils.java:259)
at
org.apache.solr.handler.component.QueryComponent.doPrefetch(QueryComponent.java:478)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:385)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
at
[JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_07) - Build # 624 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/624/ Java: 64bit/jdk1.7.0_07 -XX:+UseSerialGC No tests ran. Build Log: [...truncated 354 lines...] [javac] Compiling 320 source files to C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\build\core\classes\test [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\codecs\perfield\TestPerFieldPostingsFormat.java:27: error: package org.apache.lucene.codecs.pulsing does not exist [javac] import org.apache.lucene.codecs.pulsing.Pulsing40PostingsFormat; [javac]^ [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\codecs\perfield\TestPerFieldPostingsFormat.java:28: error: package org.apache.lucene.codecs.simpletext does not exist [javac] import org.apache.lucene.codecs.simpletext.SimpleTextPostingsFormat; [javac] ^ [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\index\TestAddIndexes.java:44: error: package org.apache.lucene.codecs.pulsing does not exist [javac] import org.apache.lucene.codecs.pulsing.Pulsing40PostingsFormat; [javac]^ [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\index\TestIndexWriter.java:33: error: package org.apache.lucene.codecs.simpletext does not exist [javac] import org.apache.lucene.codecs.simpletext.SimpleTextCodec; [javac] ^ [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\index\TestRollingUpdates.java:24: error: package org.apache.lucene.codecs.memory does not exist [javac] import org.apache.lucene.codecs.memory.MemoryPostingsFormat; [javac] ^ [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\codecs\perfield\TestPerFieldPostingsFormat.java:205: error: cannot find symbol [javac] final PostingsFormat simpleText = new SimpleTextPostingsFormat(); [javac] ^ [javac] symbol: class SimpleTextPostingsFormat [javac] location: class MockCodec [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\codecs\perfield\TestPerFieldPostingsFormat.java:222: error: cannot find symbol [javac] final PostingsFormat simpleText = new SimpleTextPostingsFormat(); [javac] ^ [javac] symbol: class SimpleTextPostingsFormat [javac] location: class MockCodec2 [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\codecs\perfield\TestPerFieldPostingsFormat.java:275: error: cannot find symbol [javac] return new Pulsing40PostingsFormat(1); [javac] ^ [javac] symbol: class Pulsing40PostingsFormat [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\codecs\perfield\TestPerFieldPostingsFormat.java:277: error: cannot find symbol [javac] return new Pulsing40PostingsFormat(1); [javac] ^ [javac] symbol: class Pulsing40PostingsFormat [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\codecs\perfield\TestPerFieldPostingsFormat.java:291: error: cannot find symbol [javac] return new Pulsing40PostingsFormat(1); [javac] ^ [javac] symbol: class Pulsing40PostingsFormat [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\codecs\perfield\TestPerFieldPostingsFormat.java:293: error: cannot find symbol [javac] return new Pulsing40PostingsFormat(2); [javac] ^ [javac] symbol: class Pulsing40PostingsFormat [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\index\TestAddIndexes.java:1194: error: cannot find symbol [javac] conf.setCodec(_TestUtil.alwaysPostingsFormat(new Pulsing40PostingsFormat(1 + random().nextInt(20; [javac]^ [javac] symbol: class Pulsing40PostingsFormat [javac] location: class TestAddIndexes [javac] C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\core\src\test\org\apache\lucene\index\TestIndexWriter.java:1399: error: cannot find symbol [javac] assumeFalse(test makes assumptions about file counts, Codec.getDefault() instanceof SimpleTextCodec); [javac] ^ [javac] symbol: class SimpleTextCodec [javac] location:
Re: [JENKINS] Lucene-Solr-trunk-Windows (64bit/jdk1.7.0_07) - Build # 624 - Failure!
Sorry, looks like something went wrong in my last commit. I'll try to fix it. -- Adrien Grand - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_07) - Build # 889 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/889/ Java: 32bit/jdk1.7.0_07 -server -XX:+UseG1GC All tests passed Build Log: [...truncated 22096 lines...] -jenkins-javadocs-lint: [...truncated 24 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:261: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:110: The following files are missing svn:eol-style (or binary svn:mime-type): * dev-tools/idea/lucene/codecs/codecs.iml * dev-tools/maven/lucene/codecs/pom.xml.template Total time: 24 minutes 23 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.7.0_07 -server -XX:+UseG1GC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4360) Support running the same test suite multiple times in parallel
[
https://issues.apache.org/jira/browse/LUCENE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448606#comment-13448606
]
Dawid Weiss commented on LUCENE-4360:
-
Example of use:
{code}
ant test-core -Dtests.dups=3 -Dtestcase=TestCharFilter
JUnit4 says kaixo! Master seed: 4CE0022F3CDFF5D7
Your default console's encoding may not display certain unicode glyphs:
windows-1252
Executing 3 suites with 3 JVMs.
Suite: org.apache.lucene.analysis.TestCharFilter
OK 0.05s J1 | TestCharFilter.testCharFilter1
OK 0.01s J1 | TestCharFilter.testCharFilter11
OK 0.00s J1 | TestCharFilter.testCharFilter2
OK 0.00s J1 | TestCharFilter.testCharFilter12
Completed on J1 in 0.35s, 4 tests
Suite: org.apache.lucene.analysis.TestCharFilter
OK 0.04s J2 | TestCharFilter.testCharFilter1
OK 0.01s J2 | TestCharFilter.testCharFilter11
OK 0.00s J2 | TestCharFilter.testCharFilter2
OK 0.01s J2 | TestCharFilter.testCharFilter12
Completed on J2 in 0.35s, 4 tests
Suite: org.apache.lucene.analysis.TestCharFilter
OK 0.04s J0 | TestCharFilter.testCharFilter1
OK 0.02s J0 | TestCharFilter.testCharFilter11
OK 0.00s J0 | TestCharFilter.testCharFilter2
OK 0.00s J0 | TestCharFilter.testCharFilter12
Completed on J0 in 0.36s, 4 tests
JVM J0: 0.67 .. 1.56 = 0.89s
JVM J1: 0.67 .. 1.55 = 0.88s
JVM J2: 0.67 .. 1.57 = 0.90s
Execution time total: 1.58 sec.
Tests summary: 3 suites, 12 tests
{code}
In combination with tests.iters:
{code}
ant test-core -Dtests.dups=2 -Dtests.iters=2 -Dtestcase=TestCharFilter
JUnit4 says íHola! Master seed: 592442048D98540B
Your default console's encoding may not display certain unicode glyphs:
windows-1252
Executing 2 suites with 2 JVMs.
Suite: org.apache.lucene.analysis.TestCharFilter
OK 0.04s J1 | TestCharFilter.testCharFilter12 {#0
seed=[592442048D98540B:5E8780464DC70845]}
OK 0.00s J1 | TestCharFilter.testCharFilter12 {#1
seed=[592442048D98540B:EAD13CBA7905C369]}
OK 0.00s J1 | TestCharFilter.testCharFilter11 {#0
seed=[592442048D98540B:4AC9FEB2457325F4]}
OK 0.00s J1 | TestCharFilter.testCharFilter11 {#1
seed=[592442048D98540B:FE9F424E71B1EED8]}
OK 0.00s J1 | TestCharFilter.testCharFilter1 {#0
seed=[592442048D98540B:643276B2D133E783]}
OK 0.00s J1 | TestCharFilter.testCharFilter1 {#1
seed=[592442048D98540B:D064CA4EE5F12CAF]}
OK 0.00s J1 | TestCharFilter.testCharFilter2 {#0
seed=[592442048D98540B:D339FCA65F87D49C]}
OK 0.01s J1 | TestCharFilter.testCharFilter2 {#1
seed=[592442048D98540B:676F405A6B451FB0]}
Completed on J1 in 0.34s, 8 tests
Suite: org.apache.lucene.analysis.TestCharFilter
OK 0.05s J0 | TestCharFilter.testCharFilter12 {#0
seed=[592442048D98540B:5E8780464DC70845]}
OK 0.00s J0 | TestCharFilter.testCharFilter12 {#1
seed=[592442048D98540B:EAD13CBA7905C369]}
OK 0.00s J0 | TestCharFilter.testCharFilter11 {#0
seed=[592442048D98540B:4AC9FEB2457325F4]}
OK 0.00s J0 | TestCharFilter.testCharFilter11 {#1
seed=[592442048D98540B:FE9F424E71B1EED8]}
OK 0.00s J0 | TestCharFilter.testCharFilter1 {#0
seed=[592442048D98540B:643276B2D133E783]}
OK 0.00s J0 | TestCharFilter.testCharFilter1 {#1
seed=[592442048D98540B:D064CA4EE5F12CAF]}
OK 0.00s J0 | TestCharFilter.testCharFilter2 {#0
seed=[592442048D98540B:D339FCA65F87D49C]}
OK 0.00s J0 | TestCharFilter.testCharFilter2 {#1
seed=[592442048D98540B:676F405A6B451FB0]}
Completed on J0 in 0.35s, 8 tests
JVM J0: 0.66 .. 1.49 = 0.82s
JVM J1: 0.66 .. 1.28 = 0.62s
Execution time total: 1.49 sec.
Tests summary: 2 suites, 16 tests
{code}
Note each JVM will start from the same master seed. Each test will work in its
own working directory and JVM though so it can be useful for performing stress
testing of a single suite.
Support running the same test suite multiple times in parallel
--
Key: LUCENE-4360
URL: https://issues.apache.org/jira/browse/LUCENE-4360
Project: Lucene - Core
Issue Type: New Feature
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0, 4.0
Attachments: quickhack.patch
The current test execution multiplier or:
{code}
-Dtests.iters=N
{code}
generates multiple tests (method executions) under a test class (suite). All
these tests, however, are bound to a single class so they must run
sequentially and on a single JVM (because of how JUnit works -- nesting of
rules, class hooks, etc.).
Mark pointed out that if somebody has a multi-core CPU then it'd be nice to
be able to run a single suite in parallel, possibly in combination with
tests.iters (so that a single test method is executed X times on Y parallel
[jira] [Resolved] (LUCENE-4360) Support running the same test suite multiple times in parallel
[
https://issues.apache.org/jira/browse/LUCENE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Dawid Weiss resolved LUCENE-4360.
-
Resolution: Fixed
Support running the same test suite multiple times in parallel
--
Key: LUCENE-4360
URL: https://issues.apache.org/jira/browse/LUCENE-4360
Project: Lucene - Core
Issue Type: New Feature
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0, 4.0
Attachments: quickhack.patch
The current test execution multiplier or:
{code}
-Dtests.iters=N
{code}
generates multiple tests (method executions) under a test class (suite). All
these tests, however, are bound to a single class so they must run
sequentially and on a single JVM (because of how JUnit works -- nesting of
rules, class hooks, etc.).
Mark pointed out that if somebody has a multi-core CPU then it'd be nice to
be able to run a single suite in parallel, possibly in combination with
tests.iters (so that a single test method is executed X times on Y parallel
JVMs).
This is surprisingly easy with the randomized runner because it currently
accepts duplicate suite names and will load-balance them in a normal way.
So, if one has Y cores (JVMs) then providing a suite name X times will result
in X executions, balanced across Y JVMs.
The only problem is how to multiply suite names. This can be done in a
number of ways, starting from a custom resource collection wrapper and ending
at a built-in code in the runner itself. I think the custom collection
wrapper approach would be interesting, I'll explore this direction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-trunk-Linux-Java7-64-test-only - Build # 4888 - Failure!
Build: builds.flonkings.com/job/Lucene-trunk-Linux-Java7-64-test-only/4888/ No tests ran. Build Log: [...truncated 332 lines...] ERROR: Failed to update http://svn.apache.org/repos/asf/lucene/dev/nightly org.tmatesoft.svn.core.SVNException: svn: Target path '/lucene/dev/nightly' does not exist svn: REPORT of /repos/asf/!svn/vcc/default: 500 Internal Server Error (http://svn.apache.org) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:64) at org.tmatesoft.svn.core.internal.wc.SVNErrorManager.error(SVNErrorManager.java:51) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.runReport(DAVRepository.java:1284) at org.tmatesoft.svn.core.internal.io.dav.DAVRepository.update(DAVRepository.java:830) at org.tmatesoft.svn.core.wc.SVNUpdateClient.update(SVNUpdateClient.java:564) at org.tmatesoft.svn.core.wc.SVNUpdateClient.doUpdate(SVNUpdateClient.java:401) at hudson.scm.subversion.UpdateUpdater$TaskImpl.perform(UpdateUpdater.java:136) at hudson.scm.subversion.WorkspaceUpdater$UpdateTask.delegateTo(WorkspaceUpdater.java:136) at hudson.scm.SubversionSCM$CheckOutTask.perform(SubversionSCM.java:788) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:769) at hudson.scm.SubversionSCM$CheckOutTask.invoke(SubversionSCM.java:753) at hudson.FilePath.act(FilePath.java:842) at hudson.FilePath.act(FilePath.java:824) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:743) at hudson.scm.SubversionSCM.checkout(SubversionSCM.java:685) at hudson.model.AbstractProject.checkout(AbstractProject.java:1249) at hudson.model.AbstractBuild$AbstractBuildExecution.defaultCheckout(AbstractBuild.java:589) at jenkins.scm.SCMCheckoutStrategy.checkout(SCMCheckoutStrategy.java:88) at hudson.model.AbstractBuild$AbstractBuildExecution.run(AbstractBuild.java:494) at hudson.model.Run.execute(Run.java:1488) at hudson.model.FreeStyleBuild.run(FreeStyleBuild.java:46) at hudson.model.ResourceController.execute(ResourceController.java:88) at hudson.model.Executor.run(Executor.java:236) Caused by: org.tmatesoft.svn.core.SVNErrorMessage: svn: Target path '/lucene/dev/nightly' does not exist at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:200) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:146) at org.tmatesoft.svn.core.SVNErrorMessage.create(SVNErrorMessage.java:89) at org.tmatesoft.svn.core.internal.io.dav.handlers.DAVErrorHandler.endElement(DAVErrorHandler.java:72) at org.tmatesoft.svn.core.internal.io.dav.handlers.BasicDAVHandler.endElement(BasicDAVHandler.java:99) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.endElement(AbstractSAXParser.java:606) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanEndElement(XMLDocumentFragmentScannerImpl.java:1741) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl$FragmentContentDriver.next(XMLDocumentFragmentScannerImpl.java:2898) at com.sun.org.apache.xerces.internal.impl.XMLDocumentScannerImpl.next(XMLDocumentScannerImpl.java:607) at com.sun.org.apache.xerces.internal.impl.XMLNSDocumentScannerImpl.next(XMLNSDocumentScannerImpl.java:116) at com.sun.org.apache.xerces.internal.impl.XMLDocumentFragmentScannerImpl.scanDocument(XMLDocumentFragmentScannerImpl.java:488) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:835) at com.sun.org.apache.xerces.internal.parsers.XML11Configuration.parse(XML11Configuration.java:764) at com.sun.org.apache.xerces.internal.parsers.XMLParser.parse(XMLParser.java:123) at com.sun.org.apache.xerces.internal.parsers.AbstractSAXParser.parse(AbstractSAXParser.java:1210) at com.sun.org.apache.xerces.internal.jaxp.SAXParserImpl$JAXPSAXParser.parse(SAXParserImpl.java:568) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:776) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readData(HTTPConnection.java:741) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.readError(HTTPConnection.java:222) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.readError(HTTPRequest.java:290) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPRequest.dispatch(HTTPRequest.java:213) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection._request(HTTPConnection.java:379) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:292) at org.tmatesoft.svn.core.internal.io.dav.http.HTTPConnection.request(HTTPConnection.java:283) at
[JENKINS] Lucene-Solr-Tests-trunk-Java6 - Build # 15182 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java6/15182/ All tests passed Build Log: [...truncated 21447 lines...] -jenkins-javadocs-lint: javadocs-lint: [...truncated 1602 lines...] javadocs-lint: [exec] [exec] Crawl/parse... [exec] [exec] build/docs/core/org/apache/lucene/store/package-use.html [exec] WARNING: anchor ../../../../org/apache/lucene/store/subclasses appears more than once [exec] [exec] Verify... [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/lucene40ords/Lucene40WithOrds.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/FixedGapTermsIndexWriter.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/lucene40ords/package-summary.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/FixedGapTermsIndexWriter.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/nestedpulsing/package-summary.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/pulsing.PulsingPostingsFormat.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/pulsing.PulsingPostingsFormat.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mocksep/MockSingleIntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/bloom/package-summary.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/bloom.BloomFilteringPostingsFormat.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/MockFixedIntBlockPostingsFormat.MockIntFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/package-tree.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mocksep/package-summary.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/MockVariableIntBlockPostingsFormat.MockIntFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/MockFixedIntBlockPostingsFormat.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec]
Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/ibm-j9-jdk6) - Build # 863 - Failure!
Sheesh, I'll dig. It's like the test is taunting me!
Mike McCandless
http://blog.mikemccandless.com
On Tue, Sep 4, 2012 at 7:29 PM, Robert Muir rcm...@gmail.com wrote:
This is after Mike's fixes in 1380802... so something else might be amiss.
On Tue, Sep 4, 2012 at 5:42 PM, Policeman Jenkins Server
jenk...@sd-datasolutions.de wrote:
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/863/
Java: 64bit/ibm-j9-jdk6
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
1 tests failed.
REGRESSION: org.apache.lucene.index.TestPostingsFormat.test
Error Message:
Stack Trace:
java.lang.OutOfMemoryError
at
__randomizedtesting.SeedInfo.seed([2945983AC7B3782C:A111A7E0694F15D4]:0)
at
org.apache.lucene.util.RamUsageEstimator$IdentityHashSet.allocateBuffers(RamUsageEstimator.java:745)
at
org.apache.lucene.util.RamUsageEstimator$IdentityHashSet.expandAndRehash(RamUsageEstimator.java:719)
at
org.apache.lucene.util.RamUsageEstimator$IdentityHashSet.add(RamUsageEstimator.java:661)
at
org.apache.lucene.util.RamUsageEstimator.measureObjectSize(RamUsageEstimator.java:420)
at
org.apache.lucene.util.RamUsageEstimator.sizeOf(RamUsageEstimator.java:333)
at
org.apache.lucene.index.TestPostingsFormat.buildIndex(TestPostingsFormat.java:386)
at
org.apache.lucene.index.TestPostingsFormat.test(TestPostingsFormat.java:926)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:345)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:769)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:429)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:40)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
[jira] [Commented] (LUCENE-4355) improve AtomicReader sugar apis
[ https://issues.apache.org/jira/browse/LUCENE-4355?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448618#comment-13448618 ] Michael McCandless commented on LUCENE-4355: I'm OK with keeping the sugar too. I agree the boilerplate code is sizable. I think only taking Term, not taking Bits, keeps the docs/positions enum simple. Should we sugar for all stats? (eg IR.getSumTotalTermFreq(String field)). improve AtomicReader sugar apis --- Key: LUCENE-4355 URL: https://issues.apache.org/jira/browse/LUCENE-4355 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir I thought about this after looking @ LUCENE-4353: AtomicReader has some sugar APIs that are over top of the flex apis (Fields, Terms, ...). But these might be a little trappy/confusing compared to 3.x. # I dont think we need AtomicReader.termDocsEnum(Bits, ...) and .termPositionsEnum(Bits, ...). I also don't think we need variants that take flags here. We should simplify these to be less trappy. I think we only need (String, BytesRef) here. # This means you need to use the flex apis for more expert usage: but we make this a bit too hard since we only let you get a Terms (which you must null check, then call .iterator() on, then seekExact, ...). I think it could help if we balanced this out by adding some sugar like AtomicReader.termsEnum? 3.x had a method that let you get a 'positioned termsenum'. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4362) ban tab-indented source
[
https://issues.apache.org/jira/browse/LUCENE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448619#comment-13448619
]
Michael McCandless commented on LUCENE-4362:
+1
ban tab-indented source
---
Key: LUCENE-4362
URL: https://issues.apache.org/jira/browse/LUCENE-4362
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4362_core.patch
This makes code really difficult to read and work with.
Its easy enough to prevent.
{noformat}
Index: build.xml
===
--- build.xml (revision 1380979)
+++ build.xml (working copy)
@@ -77,11 +77,12 @@
or
containsregexp expression=@author\b casesensitive=yes/
containsregexp expression=\bno(n|)commit\b casesensitive=no/
+ containsregexp expression=\t casesensitive=no/
/or
/fileset
map from=${validate.currDir}${file.separator} to=* /
/pathconvert
-fail if=validate.patternsFoundThe following files contain @author
tags or nocommits:${line.separator}${validate.patternsFound}/fail
+fail if=validate.patternsFoundThe following files contain @author
tags, tabs or nocommits:${line.separator}${validate.patternsFound}/fail
/target
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.7.0_07) - Build # 625 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/625/ Java: 32bit/jdk1.7.0_07 -client -XX:+UseSerialGC All tests passed Build Log: [...truncated 21858 lines...] -jenkins-javadocs-lint: [...truncated 24 lines...] BUILD FAILED C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\build.xml:261: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:110: The following files are missing svn:eol-style (or binary svn:mime-type): * dev-tools/idea/lucene/codecs/codecs.iml * dev-tools/maven/lucene/codecs/pom.xml.template Total time: 44 minutes 19 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.7.0_07 -client -XX:+UseSerialGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_35) - Build # 623 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/623/ Java: 32bit/jdk1.6.0_35 -client -XX:+UseParallelGC No tests ran. Build Log: [...truncated 363 lines...] [ivy:retrieve] SERVER ERROR: Internal Server Error url=http://oss.sonatype.org/content/repositories/releases/com/carrotsearch/randomizedtesting/junit4-ant/2.0.0/junit4-ant-2.0.0.pom [ivy:retrieve] SERVER ERROR: Internal Server Error url=http://oss.sonatype.org/content/repositories/releases/com/carrotsearch/randomizedtesting/junit4-ant/2.0.0/junit4-ant-2.0.0.jar [ivy:retrieve] SERVER ERROR: Internal Server Error url=http://oss.sonatype.org/content/repositories/releases/com/carrotsearch/randomizedtesting/randomizedtesting-runner/2.0.0/randomizedtesting-runner-2.0.0.pom [ivy:retrieve] SERVER ERROR: Internal Server Error url=http://oss.sonatype.org/content/repositories/releases/com/carrotsearch/randomizedtesting/randomizedtesting-runner/2.0.0/randomizedtesting-runner-2.0.0.jar [ivy:retrieve] [ivy:retrieve] :: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS BUILD FAILED C:\Jenkins\workspace\Lucene-Solr-4.x-Windows\build.xml:29: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-4.x-Windows\lucene\build.xml:49: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:584: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-4.x-Windows\lucene\common-build.xml:283: impossible to resolve dependencies: resolve failed - see output for details Total time: 11 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.6.0_35 -client -XX:+UseParallelGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4362) ban tab-indented source
[
https://issues.apache.org/jira/browse/LUCENE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448621#comment-13448621
]
Uwe Schindler commented on LUCENE-4362:
---
Yeah, and with the ANT check, so it is enforced!
If somebody wants to use a tab, e.g. in a string, he can always do \t
ban tab-indented source
---
Key: LUCENE-4362
URL: https://issues.apache.org/jira/browse/LUCENE-4362
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4362_core.patch
This makes code really difficult to read and work with.
Its easy enough to prevent.
{noformat}
Index: build.xml
===
--- build.xml (revision 1380979)
+++ build.xml (working copy)
@@ -77,11 +77,12 @@
or
containsregexp expression=@author\b casesensitive=yes/
containsregexp expression=\bno(n|)commit\b casesensitive=no/
+ containsregexp expression=\t casesensitive=no/
/or
/fileset
map from=${validate.currDir}${file.separator} to=* /
/pathconvert
-fail if=validate.patternsFoundThe following files contain @author
tags or nocommits:${line.separator}${validate.patternsFound}/fail
+fail if=validate.patternsFoundThe following files contain @author
tags, tabs or nocommits:${line.separator}${validate.patternsFound}/fail
/target
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_35) - Build # 623 - Failure!
I updated rr to 2.0.0 but it's only at sonatype repositories for now which seem to be flaky. The JARs should be at repo1 (maven central) within an hour. If the download breaks for you, try ant clean resolve again and again and hammer the crap out of sonatype... Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4360) Support running the same test suite multiple times in parallel
[
https://issues.apache.org/jira/browse/LUCENE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448627#comment-13448627
]
Sami Siren commented on LUCENE-4360:
Cool! This is a really nice addition!
Support running the same test suite multiple times in parallel
--
Key: LUCENE-4360
URL: https://issues.apache.org/jira/browse/LUCENE-4360
Project: Lucene - Core
Issue Type: New Feature
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0, 4.0
Attachments: quickhack.patch
The current test execution multiplier or:
{code}
-Dtests.iters=N
{code}
generates multiple tests (method executions) under a test class (suite). All
these tests, however, are bound to a single class so they must run
sequentially and on a single JVM (because of how JUnit works -- nesting of
rules, class hooks, etc.).
Mark pointed out that if somebody has a multi-core CPU then it'd be nice to
be able to run a single suite in parallel, possibly in combination with
tests.iters (so that a single test method is executed X times on Y parallel
JVMs).
This is surprisingly easy with the randomized runner because it currently
accepts duplicate suite names and will load-balance them in a normal way.
So, if one has Y cores (JVMs) then providing a suite name X times will result
in X executions, balanced across Y JVMs.
The only problem is how to multiply suite names. This can be done in a
number of ways, starting from a custom resource collection wrapper and ending
at a built-in code in the runner itself. I think the custom collection
wrapper approach would be interesting, I'll explore this direction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_07) - Build # 890 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/890/ Java: 64bit/jdk1.7.0_07 -XX:+UseG1GC All tests passed Build Log: [...truncated 12792 lines...] check-licenses: [echo] License check under: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/junit4-ant-2.0.0.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.0.jar [...truncated 1 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:64: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:155: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/custom-tasks.xml:27: License check failed. Check the logs. Total time: 25 minutes 57 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 64bit/jdk1.7.0_07 -XX:+UseG1GC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-4.x-java7 - Build # 401 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-4.x-java7/401/ 1 tests failed. REGRESSION: org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused Error Message: Should have thrown an exception. Stack Trace: java.lang.AssertionError: Should have thrown an exception. at __randomizedtesting.SeedInfo.seed([D811319C9BDB6C64:F7B8958D4C542360]:0) at org.junit.Assert.fail(Assert.java:93) at org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest.testConnectionRefused(BasicHttpSolrServerTest.java:136) 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:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:40) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:722) Build Log: [...truncated 9297 lines...] [junit4:junit4] Suite: org.apache.solr.client.solrj.impl.BasicHttpSolrServerTest [junit4:junit4] 2 0 T203 oas.SolrTestCaseJ4.initCore initCore [junit4:junit4] 2 Creating dataDir:
[jira] [Commented] (LUCENE-4360) Support running the same test suite multiple times in parallel
[
https://issues.apache.org/jira/browse/LUCENE-4360?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448631#comment-13448631
]
Dawid Weiss commented on LUCENE-4360:
-
Thanks! It was Mark's request, actually. I had all the infrastructure ready, I
just needed that duplicating resource collection and this was trivial.
Support running the same test suite multiple times in parallel
--
Key: LUCENE-4360
URL: https://issues.apache.org/jira/browse/LUCENE-4360
Project: Lucene - Core
Issue Type: New Feature
Components: general/test
Reporter: Dawid Weiss
Assignee: Dawid Weiss
Priority: Trivial
Fix For: 5.0, 4.0
Attachments: quickhack.patch
The current test execution multiplier or:
{code}
-Dtests.iters=N
{code}
generates multiple tests (method executions) under a test class (suite). All
these tests, however, are bound to a single class so they must run
sequentially and on a single JVM (because of how JUnit works -- nesting of
rules, class hooks, etc.).
Mark pointed out that if somebody has a multi-core CPU then it'd be nice to
be able to run a single suite in parallel, possibly in combination with
tests.iters (so that a single test method is executed X times on Y parallel
JVMs).
This is surprisingly easy with the randomized runner because it currently
accepts duplicate suite names and will load-balance them in a normal way.
So, if one has Y cores (JVMs) then providing a suite name X times will result
in X executions, balanced across Y JVMs.
The only problem is how to multiply suite names. This can be done in a
number of ways, starting from a custom resource collection wrapper and ending
at a built-in code in the runner itself. I think the custom collection
wrapper approach would be interesting, I'll explore this direction.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4354: Attachment: LUCENE-4354.patch here is the latest patch add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.8.0-ea-b51) - Build # 877 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/877/ Java: 32bit/jdk1.8.0-ea-b51 -server -XX:+UseSerialGC All tests passed Build Log: [...truncated 12919 lines...] check-licenses: [echo] License check under: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/test-framework/lib/junit4-ant-2.0.0.jar [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/test-framework/lib/randomizedtesting-runner-2.0.0.jar [...truncated 1 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:64: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/build.xml:155: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/custom-tasks.xml:27: License check failed. Check the logs. Total time: 26 minutes 50 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.8.0-ea-b51 -server -XX:+UseSerialGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.6.0_35) - Build # 626 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/626/ Java: 32bit/jdk1.6.0_35 -client -XX:+UseSerialGC All tests passed Build Log: [...truncated 12106 lines...] check-licenses: [echo] License check under: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene [licenses] MISSING sha1 checksum file for: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\test-framework\lib\junit4-ant-2.0.0.jar [licenses] MISSING sha1 checksum file for: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\test-framework\lib\randomizedtesting-runner-2.0.0.jar [...truncated 1 lines...] BUILD FAILED C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\build.xml:64: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:155: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\tools\custom-tasks.xml:27: License check failed. Check the logs. Total time: 44 minutes 4 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.6.0_35 -client -XX:+UseSerialGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-java7 - Build # 3164 - Failure
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-java7/3164/ All tests passed Build Log: [...truncated 12956 lines...] check-licenses: [echo] License check under: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/lucene [licenses] MISSING sha1 checksum file for: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/lucene/test-framework/lib/junit4-ant-2.0.0.jar [licenses] MISSING sha1 checksum file for: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/lucene/test-framework/lib/randomizedtesting-runner-2.0.0.jar [...truncated 1 lines...] BUILD FAILED /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/build.xml:64: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/lucene/build.xml:155: The following error occurred while executing this line: /usr/home/hudson/hudson-slave/workspace/Lucene-Solr-Tests-trunk-java7/lucene/tools/custom-tasks.xml:27: License check failed. Check the logs. Total time: 36 minutes 5 seconds Build step 'Invoke Ant' marked build as failure Recording test results Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS-MAVEN] Lucene-Solr-Maven-4.x #87: POMs out of sync
I don't understand maven: Uwe thinks it only checks the repository it already has an artifact from, is this true, Steven? Sonatype should be checked during this build but wasn't. We're still waiting for a sync with repo1. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.6.0_35) - Build # 891 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/891/ Java: 32bit/jdk1.6.0_35 -client -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 21261 lines...] -jenkins-javadocs-lint: javadocs-lint: [...truncated 1600 lines...] javadocs-lint: [exec] [exec] Crawl/parse... [exec] [exec] build/docs/core/org/apache/lucene/store/package-use.html [exec] WARNING: anchor ../../../../org/apache/lucene/store/subclasses appears more than once [exec] [exec] Verify... [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/lucene40ords/Lucene40WithOrds.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/FixedGapTermsIndexWriter.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mocksep/class-use/MockSingleIntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mocksep/MockSingleIntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/package-tree.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/lucene40ords/package-summary.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/FixedGapTermsIndexWriter.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/MockVariableIntBlockPostingsFormat.MockIntFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/MockFixedIntBlockPostingsFormat.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/bloom/TestBloomFilteredLucene40Postings.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/bloom.BloomFilteringPostingsFormat.html [exec] [exec] build/docs/codecs/org/apache/lucene/codecs/intblock/VariableIntBlockIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/intblock.VariableIntBlockIndexOutput.Index.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/intblock.VariableIntBlockIndexOutput.Index.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mocksep/package-summary.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.html [exec] [exec] build/docs/test-framework/overview-tree.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mocksep/package-use.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/bloom/package-summary.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/bloom.BloomFilteringPostingsFormat.html [exec] [exec]
[JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_35) - Build # 624 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Windows/624/ Java: 32bit/jdk1.6.0_35 -client -XX:+UseParallelGC All tests passed Build Log: [...truncated 21314 lines...] -jenkins-javadocs-lint: [...truncated 24 lines...] BUILD FAILED C:\Jenkins\workspace\Lucene-Solr-4.x-Windows\build.xml:261: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-4.x-Windows\extra-targets.xml:110: The following files are missing svn:eol-style (or binary svn:mime-type): * lucene/licenses/junit4-ant-2.0.0.jar.sha1 * lucene/licenses/randomizedtesting-runner-2.0.0.jar.sha1 * solr/licenses/junit4-ant-2.0.0.jar.sha1 * solr/licenses/randomizedtesting-runner-2.0.0.jar.sha1 Total time: 45 minutes 39 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.6.0_35 -client -XX:+UseParallelGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS-MAVEN] Lucene-Solr-Maven-4.x #87: POMs out of sync
Hi Dawid, I'm pretty sure Uwe's wrong about that - e.g., it's possible to build projects from zero downloaded dependencies. The sonatype repo declaration in the test-framework POM doesn't give an updatePolicy for releases, so the default policy, daily, is used. I think the updatePolicy is consulted only when an artifact has already been downloaded; when it isn't in the local repository, updatePolicy is ignored. In this case, v2.0.0 of randomizedtesting is missing from the local repo, so the sonatype repo should be checked; I don't understand why it wasn't. BTW, I get a 500 Internal Server Error when I visit https://oss.sonatype.org/content/repositories/releases/org/carrot2/ with my browser. Maybe Maven actually attempted to contact sonatype repo, but doesn't report failed repo connections? Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Wednesday, September 05, 2012 7:50 AM To: dev@lucene.apache.org Subject: Re: [JENKINS-MAVEN] Lucene-Solr-Maven-4.x #87: POMs out of sync I don't understand maven: Uwe thinks it only checks the repository it already has an artifact from, is this true, Steven? Sonatype should be checked during this build but wasn't. We're still waiting for a sync with repo1. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_35) - Build # 624 - Still Failing!
C:\Jenkins\workspace\Lucene-Solr-4.x-Windows\extra-targets.xml:110: The following files are missing svn:eol-style (or binary svn:mime-type): This prevents people from using alternate workflows (not using svn but git-svn for example). Can we not check svn properties but the contents instead? I know svn but I'd rather not use it. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS-MAVEN] Lucene-Solr-Maven-4.x #87: POMs out of sync
There is undoubtedly something wrong with sonatype's server -- 500 is what many of us got. But this should somehow show up in maven I think, maybe it's their bug. The updatepolicy doesn't apply here, I changed the version number (it's not a snapshot). Eh. Dawid On Wed, Sep 5, 2012 at 2:12 PM, Steven A Rowe sar...@syr.edu wrote: Hi Dawid, I'm pretty sure Uwe's wrong about that - e.g., it's possible to build projects from zero downloaded dependencies. The sonatype repo declaration in the test-framework POM doesn't give an updatePolicy for releases, so the default policy, daily, is used. I think the updatePolicy is consulted only when an artifact has already been downloaded; when it isn't in the local repository, updatePolicy is ignored. In this case, v2.0.0 of randomizedtesting is missing from the local repo, so the sonatype repo should be checked; I don't understand why it wasn't. BTW, I get a 500 Internal Server Error when I visit https://oss.sonatype.org/content/repositories/releases/org/carrot2/ with my browser. Maybe Maven actually attempted to contact sonatype repo, but doesn't report failed repo connections? Steve -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Wednesday, September 05, 2012 7:50 AM To: dev@lucene.apache.org Subject: Re: [JENKINS-MAVEN] Lucene-Solr-Maven-4.x #87: POMs out of sync I don't understand maven: Uwe thinks it only checks the repository it already has an artifact from, is this true, Steven? Sonatype should be checked during this build but wasn't. We're still waiting for a sync with repo1. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_35) - Build # 624 - Still Failing!
On Wed, Sep 5, 2012 at 8:14 AM, Dawid Weiss dwe...@apache.org wrote: C:\Jenkins\workspace\Lucene-Solr-4.x-Windows\extra-targets.xml:110: The following files are missing svn:eol-style (or binary svn:mime-type): This prevents people from using alternate workflows (not using svn but git-svn for example). Can we not check svn properties but the contents instead? I know svn but I'd rather not use it. its really necessary or it makes for huge problems with people using windows vs. linux and so on. personally I was tired of fixing this stuff before releases, so we worked on a checker. can you not configure your git-svn or whatever to add eol-style here? surely it has a configuration somewhere, for e.g. *.java. if not then its a bug in git. I did this by adding: *.sha1 = svn:eol-style=native to my ~/.subversion/config -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_35) - Build # 624 - Still Failing!
http://stackoverflow.com/questions/2127429/can-i-make-git-svn-handle-svneol-style Seems to be doable, I'll take a look. It should be an svn commit hook though, not a build time check? D. On Wed, Sep 5, 2012 at 2:17 PM, Robert Muir rcm...@gmail.com wrote: On Wed, Sep 5, 2012 at 8:14 AM, Dawid Weiss dwe...@apache.org wrote: C:\Jenkins\workspace\Lucene-Solr-4.x-Windows\extra-targets.xml:110: The following files are missing svn:eol-style (or binary svn:mime-type): This prevents people from using alternate workflows (not using svn but git-svn for example). Can we not check svn properties but the contents instead? I know svn but I'd rather not use it. its really necessary or it makes for huge problems with people using windows vs. linux and so on. personally I was tired of fixing this stuff before releases, so we worked on a checker. can you not configure your git-svn or whatever to add eol-style here? surely it has a configuration somewhere, for e.g. *.java. if not then its a bug in git. I did this by adding: *.sha1 = svn:eol-style=native to my ~/.subversion/config -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.6.0_35) - Build # 891 - Still Failing!
there are currently hundreds of broken javadocs links. i have to run out for about 10 minutes and then i will fix. I can tell you already that the .codecs package cannot have an o.a.l.codecs package duplicated with lucene-core. I will repackage appropriately and get the links fixed. On Wed, Sep 5, 2012 at 7:51 AM, Policeman Jenkins Server jenk...@sd-datasolutions.de wrote: Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/891/ Java: 32bit/jdk1.6.0_35 -client -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 21261 lines...] -jenkins-javadocs-lint: javadocs-lint: [...truncated 1600 lines...] javadocs-lint: [exec] [exec] Crawl/parse... [exec] [exec] build/docs/core/org/apache/lucene/store/package-use.html [exec] WARNING: anchor ../../../../org/apache/lucene/store/subclasses appears more than once [exec] [exec] Verify... [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/lucene40ords/Lucene40WithOrds.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/FixedGapTermsIndexWriter.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mocksep/class-use/MockSingleIntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mocksep/MockSingleIntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/package-tree.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/lucene40ords/package-summary.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/FixedGapTermsIndexWriter.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/MockVariableIntBlockPostingsFormat.MockIntFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/MockFixedIntBlockPostingsFormat.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/bloom/TestBloomFilteredLucene40Postings.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/bloom.BloomFilteringPostingsFormat.html [exec] [exec] build/docs/codecs/org/apache/lucene/codecs/intblock/VariableIntBlockIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/intblock.VariableIntBlockIndexOutput.Index.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/intblock.VariableIntBlockIndexOutput.Index.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mocksep/package-summary.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.html [exec] [exec] build/docs/test-framework/overview-tree.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK:
RE: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_35) - Build # 624 - Still Failing!
We cannot do this at apache, because the SVN is shared for all projects with different requirements, so we use a check in the builds. This check also helps to find files you missed to svn add and such stuff. You can check your own working copy with: trunk $ ant check-svn-working-copy This will report files without props, files that are not yet added (unversioned ones) and similar stuff. - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: dawid.we...@gmail.com [mailto:dawid.we...@gmail.com] On Behalf Of Dawid Weiss Sent: Wednesday, September 05, 2012 2:25 PM To: dev@lucene.apache.org Subject: Re: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_35) - Build # 624 - Still Failing! http://stackoverflow.com/questions/2127429/can-i-make-git-svn-handle- svneol-style Seems to be doable, I'll take a look. It should be an svn commit hook though, not a build time check? D. On Wed, Sep 5, 2012 at 2:17 PM, Robert Muir rcm...@gmail.com wrote: On Wed, Sep 5, 2012 at 8:14 AM, Dawid Weiss dwe...@apache.org wrote: C:\Jenkins\workspace\Lucene-Solr-4.x-Windows\extra-targets.xml:110: The following files are missing svn:eol-style (or binary svn:mime-type): This prevents people from using alternate workflows (not using svn but git-svn for example). Can we not check svn properties but the contents instead? I know svn but I'd rather not use it. its really necessary or it makes for huge problems with people using windows vs. linux and so on. personally I was tired of fixing this stuff before releases, so we worked on a checker. can you not configure your git-svn or whatever to add eol-style here? surely it has a configuration somewhere, for e.g. *.java. if not then its a bug in git. I did this by adding: *.sha1 = svn:eol-style=native to my ~/.subversion/config -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source
Interestingly, this check missed the FrenchStemFilter.java (and I
don't know what others)
that found tabs by doing a quick search of the Lucene source tree.
Does the ant task
skip deprecated classes?
I like the check, I'll see about doing something about the tabs anyway, that's
gruntwork after all...
On Wed, Sep 5, 2012 at 6:39 AM, Uwe Schindler (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/LUCENE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448621#comment-13448621
]
Uwe Schindler commented on LUCENE-4362:
---
Yeah, and with the ANT check, so it is enforced!
If somebody wants to use a tab, e.g. in a string, he can always do \t
ban tab-indented source
---
Key: LUCENE-4362
URL: https://issues.apache.org/jira/browse/LUCENE-4362
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4362_core.patch
This makes code really difficult to read and work with.
Its easy enough to prevent.
{noformat}
Index: build.xml
===
--- build.xml (revision 1380979)
+++ build.xml (working copy)
@@ -77,11 +77,12 @@
or
containsregexp expression=@author\b casesensitive=yes/
containsregexp expression=\bno(n|)commit\b casesensitive=no/
+ containsregexp expression=\t casesensitive=no/
/or
/fileset
map from=${validate.currDir}${file.separator} to=* /
/pathconvert
-fail if=validate.patternsFoundThe following files contain @author
tags or nocommits:${line.separator}${validate.patternsFound}/fail
+fail if=validate.patternsFoundThe following files contain @author
tags, tabs or nocommits:${line.separator}${validate.patternsFound}/fail
/target
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source
I'm claiming that fixing tabs isn't worth patch files, although maybe
a JIRA to track progress, agree?
On Wed, Sep 5, 2012 at 8:37 AM, Erick Erickson erickerick...@gmail.com wrote:
Interestingly, this check missed the FrenchStemFilter.java (and I
don't know what others)
that found tabs by doing a quick search of the Lucene source tree.
Does the ant task
skip deprecated classes?
I like the check, I'll see about doing something about the tabs anyway, that's
gruntwork after all...
On Wed, Sep 5, 2012 at 6:39 AM, Uwe Schindler (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/LUCENE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448621#comment-13448621
]
Uwe Schindler commented on LUCENE-4362:
---
Yeah, and with the ANT check, so it is enforced!
If somebody wants to use a tab, e.g. in a string, he can always do \t
ban tab-indented source
---
Key: LUCENE-4362
URL: https://issues.apache.org/jira/browse/LUCENE-4362
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4362_core.patch
This makes code really difficult to read and work with.
Its easy enough to prevent.
{noformat}
Index: build.xml
===
--- build.xml (revision 1380979)
+++ build.xml (working copy)
@@ -77,11 +77,12 @@
or
containsregexp expression=@author\b casesensitive=yes/
containsregexp expression=\bno(n|)commit\b
casesensitive=no/
+ containsregexp expression=\t casesensitive=no/
/or
/fileset
map from=${validate.currDir}${file.separator} to=* /
/pathconvert
-fail if=validate.patternsFoundThe following files contain @author
tags or nocommits:${line.separator}${validate.patternsFound}/fail
+fail if=validate.patternsFoundThe following files contain @author
tags, tabs or nocommits:${line.separator}${validate.patternsFound}/fail
/target
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_35) - Build # 624 - Still Failing!
You can check your own working copy with: trunk $ ant check-svn-working-copy Won't work for folks with git-svn like me, will it. This will report files without props, files that are not yet added (unversioned ones) and similar stuff. Like I said, everybody has a different workflow. The above is part of git so there's no need for this extra stuff. That's fine, I'll set those properties mentioned on stackoverflow. Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_07) - Build # 892 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/892/ Java: 32bit/jdk1.7.0_07 -server -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 21952 lines...] -jenkins-javadocs-lint: [...truncated 24 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:261: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/extra-targets.xml:110: The following files are missing svn:eol-style (or binary svn:mime-type): * lucene/licenses/junit4-ant-2.0.0.jar.sha1 * lucene/licenses/randomizedtesting-runner-2.0.0.jar.sha1 * solr/licenses/junit4-ant-2.0.0.jar.sha1 * solr/licenses/randomizedtesting-runner-2.0.0.jar.sha1 Total time: 25 minutes 34 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.7.0_07 -server -XX:+UseConcMarkSweepGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [JENKINS] Lucene-Solr-4.x-Windows (32bit/jdk1.6.0_35) - Build # 624 - Still Failing!
You can check your own working copy with: trunk $ ant check-svn-working-copy Won't work for folks with git-svn like me, will it. That was for all other people using SVN :-) So you can run this pre-commit and not wait for Jenkins to fail. Uwe - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.6.0_35) - Build # 627 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/627/ Java: 32bit/jdk1.6.0_35 -client -XX:+UseSerialGC All tests passed Build Log: [...truncated 21271 lines...] -jenkins-javadocs-lint: [...truncated 24 lines...] BUILD FAILED C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\build.xml:261: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\extra-targets.xml:110: The following files are missing svn:eol-style (or binary svn:mime-type): * lucene/licenses/junit4-ant-2.0.0.jar.sha1 * lucene/licenses/randomizedtesting-runner-2.0.0.jar.sha1 * solr/licenses/junit4-ant-2.0.0.jar.sha1 * solr/licenses/randomizedtesting-runner-2.0.0.jar.sha1 Total time: 44 minutes 31 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.6.0_35 -client -XX:+UseSerialGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-Tests-trunk-Java6 - Build # 15183 - Still Failing
Build: https://builds.apache.org/job/Lucene-Solr-Tests-trunk-Java6/15183/ All tests passed Build Log: [...truncated 21306 lines...] -jenkins-javadocs-lint: javadocs-lint: [...truncated 1603 lines...] javadocs-lint: [exec] [exec] Crawl/parse... [exec] [exec] build/docs/core/org/apache/lucene/store/package-use.html [exec] WARNING: anchor ../../../../org/apache/lucene/store/subclasses appears more than once [exec] [exec] Verify... [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/lucene40ords/Lucene40WithOrds.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/FixedGapTermsIndexWriter.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mocksep/MockSingleIntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.Reader.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/nestedpulsing/package-summary.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/pulsing.PulsingPostingsFormat.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/pulsing.PulsingPostingsFormat.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/MockFixedIntBlockPostingsFormat.MockIntFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/package-tree.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mocksep/package-summary.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/MockVariableIntBlockPostingsFormat.MockIntFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexInput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/test-framework/org/apache/lucene/codecs/mockintblock/MockFixedIntBlockPostingsFormat.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/sep.IntStreamFactory.html [exec] [exec] build/docs/codecs/org/apache/lucene/codecs/intblock/VariableIntBlockIndexOutput.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/intblock.VariableIntBlockIndexOutput.Index.html [exec] BROKEN LINK: build/docs/core/org/apache/lucene/codecs/intblock.VariableIntBlockIndexOutput.Index.html [exec] [exec] build/docs/codecs/org/apache/lucene/codecs/intblock/FixedIntBlockIndexOutput.html [exec] BROKEN LINK:
Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source
OK, through the miracles of modern IDEs I can make all the
changes (for tabs only) in just a few minutes, running tests now...
NOTE: this is just the java files, and a really stupid substitution
of two spaces for each and every tab. No, I didn't just reformat
the whole source tree, though it was tempting I'll admitG...
BUT. The freaking patch is 900K for 4x, and it touches 190 java
files. I'll be happy to check all this in, but there's a lot of code out
in branches, Git, what have you, and I want to give it a couple of
days for people to object before possibly introducing a reconciliation
nightmare.
If nobody objects by the weekend, I'll just commit (I'll create a JIRA)
both for 4x and trunk.
So a patch is indicated after all I think?
Let me know
On Wed, Sep 5, 2012 at 8:39 AM, Erick Erickson erickerick...@gmail.com wrote:
I'm claiming that fixing tabs isn't worth patch files, although maybe
a JIRA to track progress, agree?
On Wed, Sep 5, 2012 at 8:37 AM, Erick Erickson erickerick...@gmail.com
wrote:
Interestingly, this check missed the FrenchStemFilter.java (and I
don't know what others)
that found tabs by doing a quick search of the Lucene source tree.
Does the ant task
skip deprecated classes?
I like the check, I'll see about doing something about the tabs anyway,
that's
gruntwork after all...
On Wed, Sep 5, 2012 at 6:39 AM, Uwe Schindler (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/LUCENE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448621#comment-13448621
]
Uwe Schindler commented on LUCENE-4362:
---
Yeah, and with the ANT check, so it is enforced!
If somebody wants to use a tab, e.g. in a string, he can always do \t
ban tab-indented source
---
Key: LUCENE-4362
URL: https://issues.apache.org/jira/browse/LUCENE-4362
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4362_core.patch
This makes code really difficult to read and work with.
Its easy enough to prevent.
{noformat}
Index: build.xml
===
--- build.xml (revision 1380979)
+++ build.xml (working copy)
@@ -77,11 +77,12 @@
or
containsregexp expression=@author\b casesensitive=yes/
containsregexp expression=\bno(n|)commit\b
casesensitive=no/
+ containsregexp expression=\t casesensitive=no/
/or
/fileset
map from=${validate.currDir}${file.separator} to=* /
/pathconvert
-fail if=validate.patternsFoundThe following files contain @author
tags or nocommits:${line.separator}${validate.patternsFound}/fail
+fail if=validate.patternsFoundThe following files contain @author
tags, tabs or nocommits:${line.separator}${validate.patternsFound}/fail
/target
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3785) Cluster-state inconsistent
[
https://issues.apache.org/jira/browse/SOLR-3785?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sami Siren updated SOLR-3785:
-
Attachment: SOLR-3785.patch
Here's a patch that adds watches in Overseer for live nodes. When live nodes
change the cluster state is sanitized and leader flags for shards that live in
nodes other than the ones listed in live nodes are removed.
Cluster-state inconsistent
--
Key: SOLR-3785
URL: https://issues.apache.org/jira/browse/SOLR-3785
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.0
Environment: Self-build Solr release built on Apache Solr revision
1355667 from 4.x branch
Reporter: Per Steffensen
Attachments: SOLR-3785.patch
Information in CloudSolrServer.getZkStateReader().getCloudState() (called
cloudState below) seems to be inconsistent.
I have a Solr running the leader of slice sliceName in collection
collectionName - no replica to take over. I shut down this Solr, and I want
to detect that there is now no leader active.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE);
{code}
This does not work. It seems like changing state of a shard does it not
changed when this Solr goes down.
I do e.g.
{code}
ZkNodeProps leader = cloudState.getLeader(indexName, sliceName);
boolean notActive = (leader == null) ||
!leader.containsKey(ZkStateReader.STATE_PROP) ||
!leader.get(ZkStateReader.STATE_PROP).equals(ZkStateReader.ACTIVE) ||
!leader.containsKey(ZkStateReader.NODE_NAME_PROP) ||
!cloudState.getLiveNodes().contains(leader.get(ZkStateReader.NODE_NAME_PROP))
{code}
Whis works.
It seems like live-nodes of cloudState is updated when Solr goes down, but
that some of the other info available through cloudState is not - e.g.
getLeader().
This might already have already been solved on 4.x branch in a revision later
than 1355667. Then please just tell me - thanks.
Regards, Per Steffensen
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3791) SortedMapBackedCache.java throws NullPointerException
Steffen Moelter created SOLR-3791: - Summary: SortedMapBackedCache.java throws NullPointerException Key: SOLR-3791 URL: https://issues.apache.org/jira/browse/SOLR-3791 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 3.6.1 Environment: Debian Reporter: Steffen Moelter As datasource is a mysql via jdbc configured in the DIH. There are some sql statements in entities, that delivers NULL values in some fields. When this entities do have processor=CachedSqlEntityProcessor, a NullPointerException will be thrown. I Tried it on different machines, with different copies of the index. e.g.: entity processor=CachedSqlEntityProcessor name=locator_ids query= SELECT l1.id AS l1id, l2.id AS l2id, l3.id AS l3id, l4.id AS l4id, l5.id AS l5id, l6.id AS l6id, l7.id AS l7id FROM locators l1 LEFT JOIN locators l2 ON l1.parent_id = l2.id and so on delivers a result like: +---+--+--+--+--+--+--+ | l1id | l2id | l3id | l4id | l5id | l6id | l7id | +---+--+--+--+--+--+--+ | 21843 | 855 | 223 | 66 | 12 |1 | NULL | +---+--+--+--+--+--+--+ The SortedMapBackedCache throws the NullPointer. Staktrace: java.lang.NullPointerException at java.util.TreeMap.getEntry(TreeMap.java:341) at java.util.TreeMap.get(TreeMap.java:272) at org.apache.solr.handler.dataimport.SortedMapBackedCache.add(SortedMapBackedCache.java:57) at org.apache.solr.handler.dataimport.DIHCacheSupport.populateCache(DIHCacheSupport.java:124) at org.apache.solr.handler.dataimport.DIHCacheSupport.getSimpleCacheData(DIHCacheSupport.java:199) at org.apache.solr.handler.dataimport.DIHCacheSupport.getCacheData(DIHCacheSupport.java:147) at org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(EntityProcessorBase.java:132) at org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:75) at org.apache.solr.handler.dataimport.EntityProcessorWrapper.pullRow(EntityProcessorWrapper.java:330) at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:296) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:683) I had to give an onError=continue to the entity, in order to get the proper stacktrace. Leaving out the onError property (default=Abort) suppresses the stacktrace in EntityProcessorWrapper.java line 332 The DIH version 3.5.0 is not affected, works fine for me -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4340) Move all codecs but Lucene40 to a module
[ https://issues.apache.org/jira/browse/LUCENE-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448721#comment-13448721 ] Adrien Grand commented on LUCENE-4340: -- One nice side effect of moving this stuff out of core is that it makes the core JAR 280kB smaller (now 1.87MB). Move all codecs but Lucene40 to a module Key: LUCENE-4340 URL: https://issues.apache.org/jira/browse/LUCENE-4340 Project: Lucene - Core Issue Type: Task Components: core/codecs, general/build Reporter: Adrien Grand Fix For: 5.0, 4.0 Attachments: LUCENE-4340.patch, LUCENE-4340.patch, LUCENE-4340.sh We should move all concrete postings formats and codecs but Lucene40 to a module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4340) Move all codecs but Lucene40 to a module
[ https://issues.apache.org/jira/browse/LUCENE-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448724#comment-13448724 ] Robert Muir commented on LUCENE-4340: - Is there any special purpose stuff in .util used only by these codecs? I'm thinking any specialized code in o.a.l.util.packed, and probably o.a.l.util.hash? I think if its only used in one place we should just move it underneath the respective codecs/ package (not a .util) If it turns out we want it for other things then we can look at it then. Move all codecs but Lucene40 to a module Key: LUCENE-4340 URL: https://issues.apache.org/jira/browse/LUCENE-4340 Project: Lucene - Core Issue Type: Task Components: core/codecs, general/build Reporter: Adrien Grand Fix For: 5.0, 4.0 Attachments: LUCENE-4340.patch, LUCENE-4340.patch, LUCENE-4340.sh We should move all concrete postings formats and codecs but Lucene40 to a module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [jira] [Commented] (LUCENE-4362) ban tab-indented source
Erick: There is an issue about this:
https://issues.apache.org/jira/browse/LUCENE-4362
-
Uwe Schindler
H.-H.-Meier-Allee 63, D-28213 Bremen
http://www.thetaphi.de
eMail: u...@thetaphi.de
-Original Message-
From: Erick Erickson [mailto:erickerick...@gmail.com]
Sent: Wednesday, September 05, 2012 3:03 PM
To: dev@lucene.apache.org
Subject: Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source
OK, through the miracles of modern IDEs I can make all the changes (for tabs
only) in just a few minutes, running tests now...
NOTE: this is just the java files, and a really stupid substitution of two
spaces for
each and every tab. No, I didn't just reformat the whole source tree, though
it
was tempting I'll admitG...
BUT. The freaking patch is 900K for 4x, and it touches 190 java files. I'll be
happy to check all this in, but there's a lot of code out in branches, Git,
what
have you, and I want to give it a couple of days for people to object before
possibly introducing a reconciliation nightmare.
If nobody objects by the weekend, I'll just commit (I'll create a JIRA) both
for 4x
and trunk.
So a patch is indicated after all I think?
Let me know
On Wed, Sep 5, 2012 at 8:39 AM, Erick Erickson erickerick...@gmail.com
wrote:
I'm claiming that fixing tabs isn't worth patch files, although maybe
a JIRA to track progress, agree?
On Wed, Sep 5, 2012 at 8:37 AM, Erick Erickson erickerick...@gmail.com
wrote:
Interestingly, this check missed the FrenchStemFilter.java (and I
don't know what others) that found tabs by doing a quick search of
the Lucene source tree.
Does the ant task
skip deprecated classes?
I like the check, I'll see about doing something about the tabs
anyway, that's gruntwork after all...
On Wed, Sep 5, 2012 at 6:39 AM, Uwe Schindler (JIRA) j...@apache.org
wrote:
[
https://issues.apache.org/jira/browse/LUCENE-4362?page=com.atlassian
.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId
=13448621#comment-13448621 ]
Uwe Schindler commented on LUCENE-4362:
---
Yeah, and with the ANT check, so it is enforced!
If somebody wants to use a tab, e.g. in a string, he can always do
\t
ban tab-indented source
---
Key: LUCENE-4362
URL: https://issues.apache.org/jira/browse/LUCENE-4362
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4362_core.patch
This makes code really difficult to read and work with.
Its easy enough to prevent.
{noformat}
Index: build.xml
===
--- build.xml (revision 1380979)
+++ build.xml (working copy)
@@ -77,11 +77,12 @@
or
containsregexp expression=@author\b casesensitive=yes/
containsregexp expression=\bno(n|)commit\b
casesensitive=no/
+ containsregexp expression=\t casesensitive=no/
/or
/fileset
map from=${validate.currDir}${file.separator} to=* /
/pathconvert
-fail if=validate.patternsFoundThe following files contain
@author
tags or nocommits:${line.separator}${validate.patternsFound}/fail
+fail if=validate.patternsFoundThe following files contain
+ @author tags, tabs or
+ nocommits:${line.separator}${validate.patternsFound}/fail
/target
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators For more information on JIRA, see:
http://www.atlassian.com/software/jira
- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For
additional commands, e-mail: dev-h...@lucene.apache.org
-
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-4363) o.a.l.codecs should be pruned to abstract apis
Robert Muir created LUCENE-4363: --- Summary: o.a.l.codecs should be pruned to abstract apis Key: LUCENE-4363 URL: https://issues.apache.org/jira/browse/LUCENE-4363 Project: Lucene - Core Issue Type: Bug Reporter: Robert Muir This package exploded in size to a huge number of classes, Adrien cleaned up things in LUCENE-4340 but I think we have more to do. I think it should look more like o.a.l.analysis: ideally the minimal set of abstract apis: which there are too many of :) Currently there is some concrete stuff in here: e.g. i think we should just make a blocktree/ package for the blocktree stuff. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4340) Move all codecs but Lucene40 to a module
[ https://issues.apache.org/jira/browse/LUCENE-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448733#comment-13448733 ] Adrien Grand commented on LUCENE-4340: -- I think all classes in o.a.l.util.packed can be used (either directly or transitively) by DocValues at least. However, o.a.l.util.hash can be moved to lucene/codecs. Move all codecs but Lucene40 to a module Key: LUCENE-4340 URL: https://issues.apache.org/jira/browse/LUCENE-4340 Project: Lucene - Core Issue Type: Task Components: core/codecs, general/build Reporter: Adrien Grand Fix For: 5.0, 4.0 Attachments: LUCENE-4340.patch, LUCENE-4340.patch, LUCENE-4340.sh We should move all concrete postings formats and codecs but Lucene40 to a module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source
On Wed, Sep 5, 2012 at 9:03 AM, Erick Erickson erickerick...@gmail.com wrote: OK, through the miracles of modern IDEs I can make all the changes (for tabs only) in just a few minutes, running tests now... NOTE: this is just the java files, and a really stupid substitution of two spaces for each and every tab. No, I didn't just reformat the whole source tree, though it was tempting I'll admitG... BUT. The freaking patch is 900K for 4x, and it touches 190 java files. I'll be happy to check all this in, but there's a lot of code out in branches, Git, what have you, and I want to give it a couple of days for people to object before possibly introducing a reconciliation nightmare. If nobody objects by the weekend, I'll just commit (I'll create a JIRA) both for 4x and trunk. get rid of the tabs please! My only concern is that some of this is generated files: e.g. jflex generated. we shouldnt do anything to this generated code directly. -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source
No it didnt. these classes do not exist in trunk.
On Wed, Sep 5, 2012 at 8:37 AM, Erick Erickson erickerick...@gmail.com wrote:
Interestingly, this check missed the FrenchStemFilter.java (and I
don't know what others)
that found tabs by doing a quick search of the Lucene source tree.
Does the ant task
skip deprecated classes?
I like the check, I'll see about doing something about the tabs anyway, that's
gruntwork after all...
On Wed, Sep 5, 2012 at 6:39 AM, Uwe Schindler (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/LUCENE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448621#comment-13448621
]
Uwe Schindler commented on LUCENE-4362:
---
Yeah, and with the ANT check, so it is enforced!
If somebody wants to use a tab, e.g. in a string, he can always do \t
ban tab-indented source
---
Key: LUCENE-4362
URL: https://issues.apache.org/jira/browse/LUCENE-4362
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4362_core.patch
This makes code really difficult to read and work with.
Its easy enough to prevent.
{noformat}
Index: build.xml
===
--- build.xml (revision 1380979)
+++ build.xml (working copy)
@@ -77,11 +77,12 @@
or
containsregexp expression=@author\b casesensitive=yes/
containsregexp expression=\bno(n|)commit\b
casesensitive=no/
+ containsregexp expression=\t casesensitive=no/
/or
/fileset
map from=${validate.currDir}${file.separator} to=* /
/pathconvert
-fail if=validate.patternsFoundThe following files contain @author
tags or nocommits:${line.separator}${validate.patternsFound}/fail
+fail if=validate.patternsFoundThe following files contain @author
tags, tabs or nocommits:${line.separator}${validate.patternsFound}/fail
/target
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
lucidworks.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4186) Lucene spatial's distErrPct is treated as a fraction, not a percent.
[
https://issues.apache.org/jira/browse/LUCENE-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley updated LUCENE-4186:
-
Attachment: LUCENE-4186_distErrPct_upgrade.patch
This patch does a lot of things:
* SpatialArgs.toString()'s logic was moved to SpatialArgsParser as
writeSpatialArgs(args) since it looks so close to the parsed format and I'd
like to see it parsed and written in the same class.
* SpatialArgs.toString() fixes the bug in displaying the error percent that
Itamar noticed.
* Standardizes distErrPct terminology in variables and method names. Despite
the pct it's actually a fraction [0 to 0.5].
* Refactored out the logic that takes a shape and distErrPct and determines an
actual distance. It was moved from SpatialPrefixTree to SpatialArgs as a static
method calcDistanceFromErrPct(...). I don't particularly love it at
SpatialArgs but I can't think of a better place.
* Instead of SpatialArgs.distErrPct defaulting to 0.025 it defaults to null.
Now the Strategy's own distErrPct (which defaults to 0.025) is supplied to
args.resolveDistErr(...) so it can see if the args overrides the one in
strategy or not.
* SpatialArgs gains a distErr field, parsed from SpatialArgsParser. This is
an alternative means that a search request can specify the distance in a more
direct way.
One thing I didn't do, is move the distErrPct getter setter up from
PrefixTreeStrategy to the base SpatialStrategy. Given more recent discussions
about the SpatialStrategy's role, I'm torn on wether it should have options
that only one strategy will use, given what we have now.
Lucene spatial's distErrPct is treated as a fraction, not a percent.
--
Key: LUCENE-4186
URL: https://issues.apache.org/jira/browse/LUCENE-4186
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Priority: Critical
Fix For: 4.0
Attachments: LUCENE-4186_distErrPct_upgrade.patch
The distance-error-percent of a query shape in Lucene spatial is, in a
nutshell, the percent of the shape's area that is an error epsilon when
considering search detail at its edges. The default is 2.5%, for reference.
However, as configured, it is read in as a fraction:
{code:xml}
fieldType name=location_2d_trie
class=solr.SpatialRecursivePrefixTreeFieldType
distErrPct=0.025 maxDetailDist=0.001 /
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-2649) MM ignored in edismax queries with operators
[ https://issues.apache.org/jira/browse/SOLR-2649?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448742#comment-13448742 ] John Freier commented on SOLR-2649: --- Hey folks. I ran across this issue after noticing thousands of odd seeming result sets with good ol' v3.4. I don't know all of the deeper implications, but I think Jack's summary and a couple others' comments would make the most sense and are already what seem to be described in the current documentation which states that the boolean operators in front of of various terms or phrases define them to be specifically included or excluded, while the others are classified as 'optional'. Then, in the documentation on minimum match, it states that it is based the percentages etc off of the optional terms, so I would expect the boolean-specified ones not to be considered and for the mm to just be based off of whatever optionals there are. I saw this was a recent discussion so thought I'd chip in but sorry if you've already come to this conclusion and/or implemented it. Is this how the 4.0 Alpha is patched now or could anyone point me to any sort of temporary solution to achieve this functionality? Thanks for your great work. - John MM ignored in edismax queries with operators Key: SOLR-2649 URL: https://issues.apache.org/jira/browse/SOLR-2649 Project: Solr Issue Type: Bug Components: query parsers Reporter: Magnus Bergmark Priority: Minor Fix For: 4.0 Hypothetical scenario: 1. User searches for stocks oil gold with MM set to 50% 2. User adds -stockings to the query: stocks oil gold -stockings 3. User gets no hits since MM was ignored and all terms where AND-ed together The behavior seems to be intentional, although the reason why is never explained: // For correct lucene queries, turn off mm processing if there // were explicit operators (except for AND). boolean doMinMatched = (numOR + numNOT + numPluses + numMinuses) == 0; (lines 232-234 taken from tags/lucene_solr_3_3/solr/src/java/org/apache/solr/search/ExtendedDismaxQParserPlugin.java) This makes edismax unsuitable as an replacement to dismax; mm is one of the primary features of dismax. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4186) Lucene spatial's distErrPct is treated as a fraction, not a percent.
[
https://issues.apache.org/jira/browse/LUCENE-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448758#comment-13448758
]
Chris Male commented on LUCENE-4186:
bq. SpatialArgs.toString()'s logic was moved to SpatialArgsParser as
writeSpatialArgs(args) since it looks so close to the parsed format and I'd
like to see it parsed and written in the same class.
+1 Makes sense
bq. SpatialArgs.toString() fixes the bug in displaying the error percent that
Itamar noticed.
+1
bq. Standardizes distErrPct terminology in variables and method names.
Despite the pct it's actually a fraction [0 to 0.5].
+1 Do we validate somewhere that the values are between 0 and 0.5?
bq. Instead of SpatialArgs.distErrPct defaulting to 0.025 it defaults to null.
Now the Strategy's own distErrPct (which defaults to 0.025) is supplied to
args.resolveDistErr(...) so it can see if the args overrides the one in
strategy or not.
If I understand correctly, your motivation for doing this is so in the default
scenario (when no pct is defined) you have the same value at both index time
and query time, correct? I'm starting to wonder whether it makes sense to allow
the value to be set per request. Having the same value at both index and query
time seems ideal so perhaps we should force the value, whether it be the pct or
absolute value, be provided at construction of the Strategy.
bq. SpatialArgs gains a distErr field, parsed from SpatialArgsParser. This is
an alternative means that a search request can specify the distance in a more
direct way.
So can the user now provide either the the distErr or distErrPct and if they
provide the later, it is converted to the former seamlessly? Or must the user
do the conversion themselves? I'm +1 for the first option.
bq. One thing I didn't do, is move the distErrPct getter setter up from
PrefixTreeStrategy to the base SpatialStrategy.
Why would we want to move it to SpatialStrategy? It seems unrelated to the
other Strategies.
Lucene spatial's distErrPct is treated as a fraction, not a percent.
--
Key: LUCENE-4186
URL: https://issues.apache.org/jira/browse/LUCENE-4186
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Priority: Critical
Fix For: 4.0
Attachments: LUCENE-4186_distErrPct_upgrade.patch
The distance-error-percent of a query shape in Lucene spatial is, in a
nutshell, the percent of the shape's area that is an error epsilon when
considering search detail at its edges. The default is 2.5%, for reference.
However, as configured, it is read in as a fraction:
{code:xml}
fieldType name=location_2d_trie
class=solr.SpatialRecursivePrefixTreeFieldType
distErrPct=0.025 maxDetailDist=0.001 /
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-3792) NPE in highlighter under certain conditions
Yoni Amir created SOLR-3792:
---
Summary: NPE in highlighter under certain conditions
Key: SOLR-3792
URL: https://issues.apache.org/jira/browse/SOLR-3792
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 4.0-BETA
Environment: Windows 7, Java 6 or 7
Reporter: Yoni Amir
Under certain conditions, there is an exception in highlighter component. The
stacktrace is shown below.
The conditions are:
1) Add a document with a field that has empty value. E.g., with solrj api:
document.addField (field1, );
(Maybe this is not a valid value or use-case, but Solr stills allows it!!)
2) have solr.WhitespaceTokenizerFactory as the tokenizer of the analyzer chain
for that field.
3) make sure that this field should be highlighted. In my case, I was using
hl.requireFieldMatch=false, and actually I was searching on another field.
4) Using edismax, search for a phrase, e.g., foo bar (including the quotation
marks)
5) The document mentioned before should be part of the search results.
6) This exception occurs:
INFO (SolrCore.java:1670) - [rcmCore] webapp=/solr path=/select
params={qf=all_textversion=2rows=20wt=javabinstart=0q=foo bar} hits=103
status=500 QTime=38 ERROR (SolrException.java:104) -
null:java.lang.NullPointerException
at
org.apache.lucene.analysis.util.CharacterUtils$Java5CharacterUtils.fill(CharacterUtils.java:191)
at
org.apache.lucene.analysis.util.CharTokenizer.incrementToken(CharTokenizer.java:152)
at
org.apache.lucene.analysis.miscellaneous.WordDelimiterFilter.incrementToken(WordDelimiterFilter.java:209)
at
org.apache.lucene.analysis.util.FilteringTokenFilter.incrementToken(FilteringTokenFilter.java:50)
at
org.apache.lucene.analysis.miscellaneous.RemoveDuplicatesTokenFilter.incrementToken(RemoveDuplicatesTokenFilter.java:54)
at
org.apache.lucene.analysis.core.LowerCaseFilter.incrementToken(LowerCaseFilter.java:54)
at
org.apache.solr.highlight.TokenOrderingFilter.incrementToken(DefaultSolrHighlighter.java:629)
at
org.apache.lucene.analysis.CachingTokenFilter.fillCache(CachingTokenFilter.java:78)
at
org.apache.lucene.analysis.CachingTokenFilter.incrementToken(CachingTokenFilter.java:50)
at
org.apache.lucene.search.highlight.Highlighter.getBestTextFragments(Highlighter.java:225)
at
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlightingByHighlighter(DefaultSolrHighlighter.java:510)
at
org.apache.solr.highlight.DefaultSolrHighlighter.doHighlighting(DefaultSolrHighlighter.java:401)
at
org.apache.solr.handler.component.HighlightComponent.process(HighlightComponent.java:136)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:206)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1656)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:454)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:275)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:233)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:191)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:128)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:293)
at
org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:849)
at
org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:583)
at
org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:454)
at java.lang.Thread.run(Thread.java:736)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4354) add validate-maven task to check maven dependencies
[ https://issues.apache.org/jira/browse/LUCENE-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4354: Attachment: LUCENE-4354.patch merged patch up to trunk changes. add validate-maven task to check maven dependencies --- Key: LUCENE-4354 URL: https://issues.apache.org/jira/browse/LUCENE-4354 Project: Lucene - Core Issue Type: Task Reporter: Robert Muir Attachments: LUCENE-4354-dep-fix.patch, LUCENE-4354_hacked_lucene_only.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch, LUCENE-4354.patch We had a situation where the maven artifacts depended on the wrong version of tika: we should test that the maven dependencies are correct. An easy way to do this is to force it to download all of its dependencies, and then run our existing license checks over that. This currently fails: maven is bringing in some extra 3rd party libraries. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4186) Lucene spatial's distErrPct is treated as a fraction, not a percent.
[
https://issues.apache.org/jira/browse/LUCENE-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448784#comment-13448784
]
David Smiley commented on LUCENE-4186:
--
bq. +1 Do we validate somewhere that the values are between 0 and 0.5?
Yes.
bq. If I understand correctly, your motivation for doing this is so in the
default scenario (when no pct is defined) you have the same value at both index
time and query time, correct?
Yes.
bq. I'm starting to wonder whether it makes sense to allow the value to be set
per request. Having the same value at both index and query time seems ideal so
perhaps we should force the value, whether it be the pct or absolute value, be
provided at construction of the Strategy.
IMO it's quite useful to have the request specifically indicate either
distErrPct or distErr directly. I think it would be completely unworkable to
have no query-time override and fix the percentage on the strategy. It'd be
nice if this could be done at index time too but I'm not sure how it would fit
into the API. Maybe an overloaded createIndexableFields(shape,distErr)?
bq. So can the user now provide either the the distErr or distErrPct and if
they provide the later, it is converted to the former seamlessly? Or must the
user do the conversion themselves? I'm +1 for the first option.
Yeah, it's seamlessly converted when the strategy calls
args.resolveDistErr(...). The user definitely does not do any conversion
themselves.
Lucene spatial's distErrPct is treated as a fraction, not a percent.
--
Key: LUCENE-4186
URL: https://issues.apache.org/jira/browse/LUCENE-4186
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Priority: Critical
Fix For: 4.0
Attachments: LUCENE-4186_distErrPct_upgrade.patch
The distance-error-percent of a query shape in Lucene spatial is, in a
nutshell, the percent of the shape's area that is an error epsilon when
considering search detail at its edges. The default is 2.5%, for reference.
However, as configured, it is read in as a fraction:
{code:xml}
fieldType name=location_2d_trie
class=solr.SpatialRecursivePrefixTreeFieldType
distErrPct=0.025 maxDetailDist=0.001 /
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3791) SortedMapBackedCache.java throws NullPointerException
[ https://issues.apache.org/jira/browse/SOLR-3791?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] James Dyer updated SOLR-3791: - Attachment: SOLR-3791.patch Here is a patch that prevents a NPE in the case you try to enter a row into the cache with a NULL *primary key*. The solution is to silently ignore the row and discard the data. Steffen, Does this fix your issue? A better patch would add logging to this class and log a warning when a row when a NULL key is added. Also, a unit test is needed. SortedMapBackedCache.java throws NullPointerException - Key: SOLR-3791 URL: https://issues.apache.org/jira/browse/SOLR-3791 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 3.6.1 Environment: Debian Reporter: Steffen Moelter Attachments: SOLR-3791.patch As datasource is a mysql via jdbc configured in the DIH. There are some sql statements in entities, that delivers NULL values in some fields. When this entities do have processor=CachedSqlEntityProcessor, a NullPointerException will be thrown. I Tried it on different machines, with different copies of the index. e.g.: entity processor=CachedSqlEntityProcessor name=locator_ids query= SELECT l1.id AS l1id, l2.id AS l2id, l3.id AS l3id, l4.id AS l4id, l5.id AS l5id, l6.id AS l6id, l7.id AS l7id FROM locators l1 LEFT JOIN locators l2 ON l1.parent_id = l2.id and so on delivers a result like: +---+--+--+--+--+--+--+ | l1id | l2id | l3id | l4id | l5id | l6id | l7id | +---+--+--+--+--+--+--+ | 21843 | 855 | 223 | 66 | 12 |1 | NULL | +---+--+--+--+--+--+--+ The SortedMapBackedCache throws the NullPointer. Staktrace: java.lang.NullPointerException at java.util.TreeMap.getEntry(TreeMap.java:341) at java.util.TreeMap.get(TreeMap.java:272) at org.apache.solr.handler.dataimport.SortedMapBackedCache.add(SortedMapBackedCache.java:57) at org.apache.solr.handler.dataimport.DIHCacheSupport.populateCache(DIHCacheSupport.java:124) at org.apache.solr.handler.dataimport.DIHCacheSupport.getSimpleCacheData(DIHCacheSupport.java:199) at org.apache.solr.handler.dataimport.DIHCacheSupport.getCacheData(DIHCacheSupport.java:147) at org.apache.solr.handler.dataimport.EntityProcessorBase.getNext(EntityProcessorBase.java:132) at org.apache.solr.handler.dataimport.SqlEntityProcessor.nextRow(SqlEntityProcessor.java:75) at org.apache.solr.handler.dataimport.EntityProcessorWrapper.pullRow(EntityProcessorWrapper.java:330) at org.apache.solr.handler.dataimport.EntityProcessorWrapper.nextRow(EntityProcessorWrapper.java:296) at org.apache.solr.handler.dataimport.DocBuilder.buildDocument(DocBuilder.java:683) I had to give an onError=continue to the entity, in order to get the proper stacktrace. Leaving out the onError property (default=Abort) suppresses the stacktrace in EntityProcessorWrapper.java line 332 The DIH version 3.5.0 is not affected, works fine for me -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/ibm-j9-jdk6) - Build # 863 - Failure!
I was unable to reproduce this OOM.
But: it looks like it was happening due to RamUsageEstimator's
overhead of tracking which objects it has seen ... so I committed a
fix to do its own rough accounting.
Mike McCandless
http://blog.mikemccandless.com
On Tue, Sep 4, 2012 at 5:42 PM, Policeman Jenkins Server
jenk...@sd-datasolutions.de wrote:
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-4.x-Linux/863/
Java: 64bit/ibm-j9-jdk6
-Xjit:exclude={org/apache/lucene/util/fst/FST.pack(IIF)Lorg/apache/lucene/util/fst/FST;}
1 tests failed.
REGRESSION: org.apache.lucene.index.TestPostingsFormat.test
Error Message:
Stack Trace:
java.lang.OutOfMemoryError
at
__randomizedtesting.SeedInfo.seed([2945983AC7B3782C:A111A7E0694F15D4]:0)
at
org.apache.lucene.util.RamUsageEstimator$IdentityHashSet.allocateBuffers(RamUsageEstimator.java:745)
at
org.apache.lucene.util.RamUsageEstimator$IdentityHashSet.expandAndRehash(RamUsageEstimator.java:719)
at
org.apache.lucene.util.RamUsageEstimator$IdentityHashSet.add(RamUsageEstimator.java:661)
at
org.apache.lucene.util.RamUsageEstimator.measureObjectSize(RamUsageEstimator.java:420)
at
org.apache.lucene.util.RamUsageEstimator.sizeOf(RamUsageEstimator.java:333)
at
org.apache.lucene.index.TestPostingsFormat.buildIndex(TestPostingsFormat.java:386)
at
org.apache.lucene.index.TestPostingsFormat.test(TestPostingsFormat.java:926)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at
sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:48)
at
sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:600)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787)
at
org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50)
at
org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:345)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:769)
at
com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:429)
at
com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682)
at
com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693)
at
org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45)
at
org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42)
at
com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39)
at
org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:40)
at
org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48)
at
org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70)
at
[jira] [Commented] (SOLR-3790) NullPointerException and ConcurrentModificationException are thrown when searching with highlighter
[
https://issues.apache.org/jira/browse/SOLR-3790?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448798#comment-13448798
]
Koji Sekiguchi commented on SOLR-3790:
--
Hmm, this is not good. I think storedHighlightFieldNames in SolrIndexSearcher
could be initialized twice in getStoredHighlightFieldNames() method:
{code}
public CollectionString getStoredHighlightFieldNames() {
if (storedHighlightFieldNames == null) {
storedHighlightFieldNames = new LinkedListString();
for (String fieldName : fieldNames) {
try {
SchemaField field = schema.getField(fieldName);
if (field.stored()
((field.getType() instanceof
org.apache.solr.schema.TextField) ||
(field.getType() instanceof
org.apache.solr.schema.StrField))) {
storedHighlightFieldNames.add(fieldName);
}
} catch (RuntimeException e) { // getField() throws a SolrException,
but it arrives as a RuntimeException
log.warn(Field \ + fieldName + \ found in index, but not
defined in schema.);
}
}
}
return storedHighlightFieldNames;
}
{code}
I think the initialization block should go to constructor. Meanwhile, Aoki-san,
you can avoid the bug by specifying the explicit field names for hl.fl
parameter instead of using *.
NullPointerException and ConcurrentModificationException are thrown when
searching with highlighter
---
Key: SOLR-3790
URL: https://issues.apache.org/jira/browse/SOLR-3790
Project: Solr
Issue Type: Bug
Components: highlighter
Affects Versions: 3.5
Environment: Ubuntu 12.04, Solr 3.5
Reporter: shou aoki
Hi, Im using Solr 3.5.
I found strange phenomenon in solr log.
This phenomenon has two exceptions that NullPointerException and
ConcurrentModificationException.
These exceptions are thrown by discrete threads.
I think, The same two queries thrown at same time because error log recorded
at same time. But I can't reproduce it.
Does anyone have the same phenomenon?
{code}
2012-08-21 00:07:49,868 [qtp979682126-953] INFO SolrCore - [c3] webapp=/solr
path=/select
params={hl.tag.post=[%02]sort=score+deschl.tag.pre=[%01]hl.fl=*wt=javabinhl=truedefType=normalizeQParserrows=40version=2fl=score,*hl.useFastVectorHighlighter=truestart=0q=hogefq=((ap.l:771)+AND+(*:*))}
hits=4 status=500 QTime=164
2012-08-21 00:07:49,868 [qtp979682126-938] INFO SolrCore - [c3] webapp=/solr
path=/select
params={hl.tag.post=[%02]sort=score+deschl.tag.pre=[%01]hl.fl=*wt=javabinhl=truedefType=normalizeQParserrows=12version=2fl=score,*hl.useFastVectorHighlighter=truestart=0q=hogefq=((ap.l:771)+AND+(*:*))}
hits=4 status=500 QTime=1094
2012-08-21 00:07:49,873 [qtp979682126-953] ERROR SolrDispatchFilter -
java.util.ConcurrentModificationException
at
java.util.LinkedList$ListItr.checkForComodification(LinkedList.java:778)
at java.util.LinkedList$ListItr.next(LinkedList.java:713)
at
org.apache.solr.highlight.SolrHighlighter.getHighlightFields(SolrHighlighter.java:106)
at
org.apache.solr.util.SolrPluginUtils.optimizePreFetchDocs(SolrPluginUtils.java:259)
at
org.apache.solr.handler.component.QueryComponent.doPrefetch(QueryComponent.java:478)
at
org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:385)
at
org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:194)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:129)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1372)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:356)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:252)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1337)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:486)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:119)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:520)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:233)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:973)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:417)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:192)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:907)
at
[jira] [Commented] (LUCENE-4186) Lucene spatial's distErrPct is treated as a fraction, not a percent.
[
https://issues.apache.org/jira/browse/LUCENE-4186?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448801#comment-13448801
]
Chris Male commented on LUCENE-4186:
bq. It'd be nice if this could be done at index time too but I'm not sure how
it would fit into the API. Maybe an overloaded
createIndexableFields(shape,distErr)
I've always thought it was a little unusual createIndexableFields didn't also
accept SpatialArgs, so why don't we change it so it does?
Lucene spatial's distErrPct is treated as a fraction, not a percent.
--
Key: LUCENE-4186
URL: https://issues.apache.org/jira/browse/LUCENE-4186
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Reporter: David Smiley
Assignee: David Smiley
Priority: Critical
Fix For: 4.0
Attachments: LUCENE-4186_distErrPct_upgrade.patch
The distance-error-percent of a query shape in Lucene spatial is, in a
nutshell, the percent of the shape's area that is an error epsilon when
considering search detail at its edges. The default is 2.5%, for reference.
However, as configured, it is read in as a fraction:
{code:xml}
fieldType name=location_2d_trie
class=solr.SpatialRecursivePrefixTreeFieldType
distErrPct=0.025 maxDetailDist=0.001 /
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source
@Uwe: Right, wasn't thinking, a fairly common happening.
Note that this is fairly ugly in that the simple-minded substitution
I did isn't totally right. You get diff lines like:
return new FloatDocValues(this) {
@Override
public float floatVal(int doc) {
- return func(doc, vals);
+ return func(doc, vals);
}
@Override
public String toString(int doc) {
- return name() + '(' + vals.toString(doc) + ')';
+ return name() + '(' + vals.toString(doc) + ')';
}
};
}
where the tab stops were other than 2 spaces. Unfortunately, I think the
alternative is to reformat all the files where this substitution was done
or go through by hand and do them all. And I'm really reluctant to volunteer
to fix over 8,000 of these by hand.
I'd _like_ to reformat all the files, but we all know the problems
there. I propose
that if nobody (or not enough people) object, I'll check them in with the
ugly indentation and the bad indents can be fixed when people are working
on the specific sections of code. At least it's progress.
Or if the consensus is to reformat the offending files I can do that. Tedious
but not that time-consuming.
Let me know...
On Wed, Sep 5, 2012 at 9:50 AM, Robert Muir rcm...@gmail.com wrote:
No it didnt. these classes do not exist in trunk.
On Wed, Sep 5, 2012 at 8:37 AM, Erick Erickson erickerick...@gmail.com
wrote:
Interestingly, this check missed the FrenchStemFilter.java (and I
don't know what others)
that found tabs by doing a quick search of the Lucene source tree.
Does the ant task
skip deprecated classes?
I like the check, I'll see about doing something about the tabs anyway,
that's
gruntwork after all...
On Wed, Sep 5, 2012 at 6:39 AM, Uwe Schindler (JIRA) j...@apache.org wrote:
[
https://issues.apache.org/jira/browse/LUCENE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448621#comment-13448621
]
Uwe Schindler commented on LUCENE-4362:
---
Yeah, and with the ANT check, so it is enforced!
If somebody wants to use a tab, e.g. in a string, he can always do \t
ban tab-indented source
---
Key: LUCENE-4362
URL: https://issues.apache.org/jira/browse/LUCENE-4362
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4362_core.patch
This makes code really difficult to read and work with.
Its easy enough to prevent.
{noformat}
Index: build.xml
===
--- build.xml (revision 1380979)
+++ build.xml (working copy)
@@ -77,11 +77,12 @@
or
containsregexp expression=@author\b casesensitive=yes/
containsregexp expression=\bno(n|)commit\b
casesensitive=no/
+ containsregexp expression=\t casesensitive=no/
/or
/fileset
map from=${validate.currDir}${file.separator} to=* /
/pathconvert
-fail if=validate.patternsFoundThe following files contain @author
tags or nocommits:${line.separator}${validate.patternsFound}/fail
+fail if=validate.patternsFoundThe following files contain @author
tags, tabs or nocommits:${line.separator}${validate.patternsFound}/fail
/target
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA
administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
--
lucidworks.com
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/ibm-j9-jdk6) - Build # 863 - Failure!
But: it looks like it was happening due to RamUsageEstimator's overhead of tracking which objects it has seen ... so I committed a fix to do its own rough accounting. This can amount to some cost, true, the cost of the set (table of references). Dawid - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4123) Add CachingRAMDirectory
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448829#comment-13448829
]
Shai Erera commented on LUCENE-4123:
Besides Uwe's ideas for improvements, is this Directory operable? I.e., if you
chose to commit what you have accomplished so far, do tests fail? Is it safe to
use?
I'm thinking progress, not perfection -- we can always introduce improvements
later.
Add CachingRAMDirectory
---
Key: LUCENE-4123
URL: https://issues.apache.org/jira/browse/LUCENE-4123
Project: Lucene - Core
Issue Type: Bug
Components: core/store
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-4123.patch
The directory is very simple and useful if you have an index that you
know fully fits into available RAM. You could also use FileSwitchDir if
you want to leave some files (eg stored fields or term vectors) on disk.
It wraps any other Directory and delegates all writing (IndexOutput) to
it, but for reading (IndexInput), it allocates a single byte[] and fully
reads the file in and then serves requests off that single byte[]. It's
more GC friendly than RAMDir since it only allocates a single array per
file.
It has a few nocommits still, but all tests pass if I wrap the delegate
inside MockDirectoryWrapper using this.
I tested with 1M Wikipedia english index (would like to test w/ 10M docs
but I don't have enough RAM...); it seems to give a nice speedup:
{noformat}
TaskQPS base StdDev base QPS cachedStdDev cached
Pct diff
Respell 197.007.27 203.198.17 -4% -
11%
PKLookup 121.122.80 125.463.20 -1% -
8%
Fuzzy2 66.622.62 69.912.85 -3% -
13%
Fuzzy1 206.206.47 222.216.521% -
14%
TermGroup100K 160.146.62 175.713.793% -
16%
Phrase 34.850.40 38.750.618% -
14%
TermBGroup100K 363.75 15.74 406.98 13.233% -
20%
SpanNear 53.081.11 59.532.944% -
20%
TermBGroup100K1P 222.539.78 252.865.966% -
21%
SloppyPhrase 70.362.05 79.954.484% -
23%
Wildcard 238.104.29 272.784.97 10% -
18%
OrHighMed 123.494.85 149.324.66 12% -
29%
Prefix3 288.468.10 350.405.38 16% -
26%
OrHighHigh 76.463.27 93.132.96 13% -
31%
IntNRQ 92.252.12 113.475.74 14% -
32%
Term 757.12 39.03 958.62 22.68 17% -
36%
AndHighHigh 103.034.48 133.893.76 21% -
39%
AndHighMed 376.36 16.58 493.99 10.00 23% -
40%
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4362) ban tab-indented source
[
https://issues.apache.org/jira/browse/LUCENE-4362?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Robert Muir updated LUCENE-4362:
Attachment: LUCENE-4362.patch
updated patch to trunk, and fixed a few more files with just stray tabs.
ban tab-indented source
---
Key: LUCENE-4362
URL: https://issues.apache.org/jira/browse/LUCENE-4362
Project: Lucene - Core
Issue Type: Task
Reporter: Robert Muir
Attachments: LUCENE-4362_core.patch, LUCENE-4362.patch
This makes code really difficult to read and work with.
Its easy enough to prevent.
{noformat}
Index: build.xml
===
--- build.xml (revision 1380979)
+++ build.xml (working copy)
@@ -77,11 +77,12 @@
or
containsregexp expression=@author\b casesensitive=yes/
containsregexp expression=\bno(n|)commit\b casesensitive=no/
+ containsregexp expression=\t casesensitive=no/
/or
/fileset
map from=${validate.currDir}${file.separator} to=* /
/pathconvert
-fail if=validate.patternsFoundThe following files contain @author
tags or nocommits:${line.separator}${validate.patternsFound}/fail
+fail if=validate.patternsFoundThe following files contain @author
tags, tabs or nocommits:${line.separator}${validate.patternsFound}/fail
/target
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source
On Wed, Sep 5, 2012 at 11:04 AM, Erick Erickson erickerick...@gmail.com wrote: @Uwe: Right, wasn't thinking, a fairly common happening. Note that this is fairly ugly in that the simple-minded substitution I did isn't totally right. You get diff lines like: I think the automatic 2-space replacement is fine for hopeless files. I updated the patch on LUCENE-4362 with fixes for files that aren't hopeless, just have a few stray tabs. If you want, just assign the issue, but maybe apply that patch before doing anything automatic? I was careful with those files (some had tables etc that should be aligned). -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4123) Add CachingRAMDirectory
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448842#comment-13448842
]
Michael McCandless commented on LUCENE-4123:
I believe it is safe ... eg all tests pass if I wrap MDW's delegate w/ this in
newDirectory ...
I'll update the patch w/ Uwe and Robert's suggestions ...
Add CachingRAMDirectory
---
Key: LUCENE-4123
URL: https://issues.apache.org/jira/browse/LUCENE-4123
Project: Lucene - Core
Issue Type: Bug
Components: core/store
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-4123.patch
The directory is very simple and useful if you have an index that you
know fully fits into available RAM. You could also use FileSwitchDir if
you want to leave some files (eg stored fields or term vectors) on disk.
It wraps any other Directory and delegates all writing (IndexOutput) to
it, but for reading (IndexInput), it allocates a single byte[] and fully
reads the file in and then serves requests off that single byte[]. It's
more GC friendly than RAMDir since it only allocates a single array per
file.
It has a few nocommits still, but all tests pass if I wrap the delegate
inside MockDirectoryWrapper using this.
I tested with 1M Wikipedia english index (would like to test w/ 10M docs
but I don't have enough RAM...); it seems to give a nice speedup:
{noformat}
TaskQPS base StdDev base QPS cachedStdDev cached
Pct diff
Respell 197.007.27 203.198.17 -4% -
11%
PKLookup 121.122.80 125.463.20 -1% -
8%
Fuzzy2 66.622.62 69.912.85 -3% -
13%
Fuzzy1 206.206.47 222.216.521% -
14%
TermGroup100K 160.146.62 175.713.793% -
16%
Phrase 34.850.40 38.750.618% -
14%
TermBGroup100K 363.75 15.74 406.98 13.233% -
20%
SpanNear 53.081.11 59.532.944% -
20%
TermBGroup100K1P 222.539.78 252.865.966% -
21%
SloppyPhrase 70.362.05 79.954.484% -
23%
Wildcard 238.104.29 272.784.97 10% -
18%
OrHighMed 123.494.85 149.324.66 12% -
29%
Prefix3 288.468.10 350.405.38 16% -
26%
OrHighHigh 76.463.27 93.132.96 13% -
31%
IntNRQ 92.252.12 113.475.74 14% -
32%
Term 757.12 39.03 958.62 22.68 17% -
36%
AndHighHigh 103.034.48 133.893.76 21% -
39%
AndHighMed 376.36 16.58 493.99 10.00 23% -
40%
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-4123) Add CachingRAMDirectory
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael McCandless updated LUCENE-4123:
---
Attachment: LUCENE-4123.patch
New patch, catching AIOOBE and throwing EOFException, and removing the
specialized impls.
I moved it to core temporarily to make it easier to test (add
-Dtests.directory=CachingRAMDirectory). I'll move it back to misc/ before
committing ...
Add CachingRAMDirectory
---
Key: LUCENE-4123
URL: https://issues.apache.org/jira/browse/LUCENE-4123
Project: Lucene - Core
Issue Type: Bug
Components: core/store
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-4123.patch, LUCENE-4123.patch
The directory is very simple and useful if you have an index that you
know fully fits into available RAM. You could also use FileSwitchDir if
you want to leave some files (eg stored fields or term vectors) on disk.
It wraps any other Directory and delegates all writing (IndexOutput) to
it, but for reading (IndexInput), it allocates a single byte[] and fully
reads the file in and then serves requests off that single byte[]. It's
more GC friendly than RAMDir since it only allocates a single array per
file.
It has a few nocommits still, but all tests pass if I wrap the delegate
inside MockDirectoryWrapper using this.
I tested with 1M Wikipedia english index (would like to test w/ 10M docs
but I don't have enough RAM...); it seems to give a nice speedup:
{noformat}
TaskQPS base StdDev base QPS cachedStdDev cached
Pct diff
Respell 197.007.27 203.198.17 -4% -
11%
PKLookup 121.122.80 125.463.20 -1% -
8%
Fuzzy2 66.622.62 69.912.85 -3% -
13%
Fuzzy1 206.206.47 222.216.521% -
14%
TermGroup100K 160.146.62 175.713.793% -
16%
Phrase 34.850.40 38.750.618% -
14%
TermBGroup100K 363.75 15.74 406.98 13.233% -
20%
SpanNear 53.081.11 59.532.944% -
20%
TermBGroup100K1P 222.539.78 252.865.966% -
21%
SloppyPhrase 70.362.05 79.954.484% -
23%
Wildcard 238.104.29 272.784.97 10% -
18%
OrHighMed 123.494.85 149.324.66 12% -
29%
Prefix3 288.468.10 350.405.38 16% -
26%
OrHighHigh 76.463.27 93.132.96 13% -
31%
IntNRQ 92.252.12 113.475.74 14% -
32%
Term 757.12 39.03 958.62 22.68 17% -
36%
AndHighHigh 103.034.48 133.893.76 21% -
39%
AndHighMed 376.36 16.58 493.99 10.00 23% -
40%
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_07) - Build # 896 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/896/ Java: 32bit/jdk1.7.0_07 -client -XX:+UseParallelGC 1 tests failed. REGRESSION: org.apache.lucene.spatial.prefix.TestRecursivePrefixTreeStrategy.geohashRecursiveRandom Error Message: Intersects(Circle(Pt(x=1.8440186977386475E-6,y=2.0954757928848267E-6), d=0.0° 0.00km) distPrec=0.00%) expected:20 but was:19 Stack Trace: java.lang.AssertionError: Intersects(Circle(Pt(x=1.8440186977386475E-6,y=2.0954757928848267E-6), d=0.0° 0.00km) distPrec=0.00%) expected:20 but was:19 at __randomizedtesting.SeedInfo.seed([64AEB5731816C437:EDD24BC166DD9]:0) at org.junit.Assert.fail(Assert.java:93) at org.junit.Assert.failNotEquals(Assert.java:647) at org.junit.Assert.assertEquals(Assert.java:128) at org.junit.Assert.assertEquals(Assert.java:472) at org.apache.lucene.spatial.prefix.TestRecursivePrefixTreeStrategy.checkHits(TestRecursivePrefixTreeStrategy.java:189) at org.apache.lucene.spatial.prefix.TestRecursivePrefixTreeStrategy.geohashRecursiveRandom(TestRecursivePrefixTreeStrategy.java:151) 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:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:45) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:40) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at java.lang.Thread.run(Thread.java:722) Build Log: [...truncated 6955 lines...] [junit4:junit4] Suite:
Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/ibm-j9-jdk6) - Build # 863 - Failure!
On Wed, Sep 5, 2012 at 11:26 AM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: But: it looks like it was happening due to RamUsageEstimator's overhead of tracking which objects it has seen ... so I committed a fix to do its own rough accounting. This can amount to some cost, true, the cost of the set (table of references). Yeah ... this test in particular is object-heavy (one object per term doc+position occurrence!) so I think it amounted to non-trivial extra RAM ... But it was odd I could not repro ... Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/ibm-j9-jdk6) - Build # 863 - Failure!
But it was odd I could not repro ... Same JVM, same settings? Perhaps a different default heap? - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4123) Add CachingRAMDirectory
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448870#comment-13448870
]
Robert Muir commented on LUCENE-4123:
-
looks good... i dont really like that close() is a no-op and that seek() has no
checks (since its deferred, if you seek somewhere negative you wont know until
later).
you could probably fix both of these, e.g. keep the byte[] final but let
close() turn set the position negative, catch NegativeArray and throw ACE.
then just throw IAE on seek if the incoming long is negative at least, since
you reserve it to mean closed.
I also don't like that its a delegator.
should the underlying read check for BufferedII and pass useBuffer=false?
Add CachingRAMDirectory
---
Key: LUCENE-4123
URL: https://issues.apache.org/jira/browse/LUCENE-4123
Project: Lucene - Core
Issue Type: Bug
Components: core/store
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-4123.patch, LUCENE-4123.patch
The directory is very simple and useful if you have an index that you
know fully fits into available RAM. You could also use FileSwitchDir if
you want to leave some files (eg stored fields or term vectors) on disk.
It wraps any other Directory and delegates all writing (IndexOutput) to
it, but for reading (IndexInput), it allocates a single byte[] and fully
reads the file in and then serves requests off that single byte[]. It's
more GC friendly than RAMDir since it only allocates a single array per
file.
It has a few nocommits still, but all tests pass if I wrap the delegate
inside MockDirectoryWrapper using this.
I tested with 1M Wikipedia english index (would like to test w/ 10M docs
but I don't have enough RAM...); it seems to give a nice speedup:
{noformat}
TaskQPS base StdDev base QPS cachedStdDev cached
Pct diff
Respell 197.007.27 203.198.17 -4% -
11%
PKLookup 121.122.80 125.463.20 -1% -
8%
Fuzzy2 66.622.62 69.912.85 -3% -
13%
Fuzzy1 206.206.47 222.216.521% -
14%
TermGroup100K 160.146.62 175.713.793% -
16%
Phrase 34.850.40 38.750.618% -
14%
TermBGroup100K 363.75 15.74 406.98 13.233% -
20%
SpanNear 53.081.11 59.532.944% -
20%
TermBGroup100K1P 222.539.78 252.865.966% -
21%
SloppyPhrase 70.362.05 79.954.484% -
23%
Wildcard 238.104.29 272.784.97 10% -
18%
OrHighMed 123.494.85 149.324.66 12% -
29%
Prefix3 288.468.10 350.405.38 16% -
26%
OrHighHigh 76.463.27 93.132.96 13% -
31%
IntNRQ 92.252.12 113.475.74 14% -
32%
Term 757.12 39.03 958.62 22.68 17% -
36%
AndHighHigh 103.034.48 133.893.76 21% -
39%
AndHighMed 376.36 16.58 493.99 10.00 23% -
40%
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-4.x-Linux (64bit/ibm-j9-jdk6) - Build # 863 - Failure!
On Wed, Sep 5, 2012 at 12:33 PM, Dawid Weiss dawid.we...@cs.put.poznan.pl wrote: But it was odd I could not repro ... Same JVM, same settings? Perhaps a different default heap? Aha! I had failed to use the same (IBM) JVM ... now that I tried that, I can reproduce. So it does not OOM under Oracle's JVM but does under IBM's ... And then I re-ran with IBM's JVM after my commit and the test now passes. Phew :) Mike McCandless http://blog.mikemccandless.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source
I'll be happy to. I got the patches and applied them, but I can't assign the JIRA to myself. I can in Solr, but in Lucene I don't have the assign tab displayed. Who do I talk to? Erick On Wed, Sep 5, 2012 at 11:57 AM, Robert Muir rcm...@gmail.com wrote: On Wed, Sep 5, 2012 at 11:04 AM, Erick Erickson erickerick...@gmail.com wrote: @Uwe: Right, wasn't thinking, a fairly common happening. Note that this is fairly ugly in that the simple-minded substitution I did isn't totally right. You get diff lines like: I think the automatic 2-space replacement is fine for hopeless files. I updated the patch on LUCENE-4362 with fixes for files that aren't hopeless, just have a few stray tabs. If you want, just assign the issue, but maybe apply that patch before doing anything automatic? I was careful with those files (some had tables etc that should be aligned). -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4123) Add CachingRAMDirectory
[
https://issues.apache.org/jira/browse/LUCENE-4123?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448884#comment-13448884
]
Robert Muir commented on LUCENE-4123:
-
also readBytes should not catch ArrayIndexOutOfBoundsException. it must be the
more general IndexOutOfBoundsException.
Add CachingRAMDirectory
---
Key: LUCENE-4123
URL: https://issues.apache.org/jira/browse/LUCENE-4123
Project: Lucene - Core
Issue Type: Bug
Components: core/store
Reporter: Michael McCandless
Assignee: Michael McCandless
Attachments: LUCENE-4123.patch, LUCENE-4123.patch
The directory is very simple and useful if you have an index that you
know fully fits into available RAM. You could also use FileSwitchDir if
you want to leave some files (eg stored fields or term vectors) on disk.
It wraps any other Directory and delegates all writing (IndexOutput) to
it, but for reading (IndexInput), it allocates a single byte[] and fully
reads the file in and then serves requests off that single byte[]. It's
more GC friendly than RAMDir since it only allocates a single array per
file.
It has a few nocommits still, but all tests pass if I wrap the delegate
inside MockDirectoryWrapper using this.
I tested with 1M Wikipedia english index (would like to test w/ 10M docs
but I don't have enough RAM...); it seems to give a nice speedup:
{noformat}
TaskQPS base StdDev base QPS cachedStdDev cached
Pct diff
Respell 197.007.27 203.198.17 -4% -
11%
PKLookup 121.122.80 125.463.20 -1% -
8%
Fuzzy2 66.622.62 69.912.85 -3% -
13%
Fuzzy1 206.206.47 222.216.521% -
14%
TermGroup100K 160.146.62 175.713.793% -
16%
Phrase 34.850.40 38.750.618% -
14%
TermBGroup100K 363.75 15.74 406.98 13.233% -
20%
SpanNear 53.081.11 59.532.944% -
20%
TermBGroup100K1P 222.539.78 252.865.966% -
21%
SloppyPhrase 70.362.05 79.954.484% -
23%
Wildcard 238.104.29 272.784.97 10% -
18%
OrHighMed 123.494.85 149.324.66 12% -
29%
Prefix3 288.468.10 350.405.38 16% -
26%
OrHighHigh 76.463.27 93.132.96 13% -
31%
IntNRQ 92.252.12 113.475.74 14% -
32%
Term 757.12 39.03 958.62 22.68 17% -
36%
AndHighHigh 103.034.48 133.893.76 21% -
39%
AndHighMed 376.36 16.58 493.99 10.00 23% -
40%
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [jira] [Commented] (LUCENE-4362) ban tab-indented source
Hi Erick, I think I can add you to the appropriate group. Trying now. Steve -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Wednesday, September 05, 2012 12:56 PM To: dev@lucene.apache.org Subject: Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source I'll be happy to. I got the patches and applied them, but I can't assign the JIRA to myself. I can in Solr, but in Lucene I don't have the assign tab displayed. Who do I talk to? Erick On Wed, Sep 5, 2012 at 11:57 AM, Robert Muir rcm...@gmail.com wrote: On Wed, Sep 5, 2012 at 11:04 AM, Erick Erickson erickerick...@gmail.com wrote: @Uwe: Right, wasn't thinking, a fairly common happening. Note that this is fairly ugly in that the simple-minded substitution I did isn't totally right. You get diff lines like: I think the automatic 2-space replacement is fine for hopeless files. I updated the patch on LUCENE-4362 with fixes for files that aren't hopeless, just have a few stray tabs. If you want, just assign the issue, but maybe apply that patch before doing anything automatic? I was careful with those files (some had tables etc that should be aligned). -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source
I took care of it. THe problem was 2 Erick Ericksons. one was erick.erick...@gmail.com (that one had permissions), but that either isn't you, or was an old address. I put your new one in there and disabled access for the other one On Wed, Sep 5, 2012 at 12:59 PM, Steven A Rowe sar...@syr.edu wrote: Hi Erick, I think I can add you to the appropriate group. Trying now. Steve -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Wednesday, September 05, 2012 12:56 PM To: dev@lucene.apache.org Subject: Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source I'll be happy to. I got the patches and applied them, but I can't assign the JIRA to myself. I can in Solr, but in Lucene I don't have the assign tab displayed. Who do I talk to? Erick On Wed, Sep 5, 2012 at 11:57 AM, Robert Muir rcm...@gmail.com wrote: On Wed, Sep 5, 2012 at 11:04 AM, Erick Erickson erickerick...@gmail.com wrote: @Uwe: Right, wasn't thinking, a fairly common happening. Note that this is fairly ugly in that the simple-minded substitution I did isn't totally right. You get diff lines like: I think the automatic 2-space replacement is fine for hopeless files. I updated the patch on LUCENE-4362 with fixes for files that aren't hopeless, just have a few stray tabs. If you want, just assign the issue, but maybe apply that patch before doing anything automatic? I was careful with those files (some had tables etc that should be aligned). -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4340) Move all codecs but Lucene40 to a module
[ https://issues.apache.org/jira/browse/LUCENE-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448887#comment-13448887 ] Adrien Grand commented on LUCENE-4340: -- I was trying to move the bloom utilities (oal.util.hash and oal.util.FuzzySet) to lucene/codecs but the problem is that SolrResourceLoader imports HashFunction in order to be able to reload SPI implementations. Robert just suggested that a SPI is maybe a little over-engineered here so I'm thinking of hardwiring HashFunction to MurmurHash2 (if at some point we feel we would like to change the hash implementation, all we need to do is to bump the version number). Move all codecs but Lucene40 to a module Key: LUCENE-4340 URL: https://issues.apache.org/jira/browse/LUCENE-4340 Project: Lucene - Core Issue Type: Task Components: core/codecs, general/build Reporter: Adrien Grand Fix For: 5.0, 4.0 Attachments: LUCENE-4340.patch, LUCENE-4340.patch, LUCENE-4340.sh We should move all concrete postings formats and codecs but Lucene40 to a module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [jira] [Commented] (LUCENE-4362) ban tab-indented source
I was wondering why Erick's name was already in the Administrators group... Thanks Robert. -Original Message- From: Robert Muir [mailto:rcm...@gmail.com] Sent: Wednesday, September 05, 2012 1:02 PM To: dev@lucene.apache.org Subject: Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source I took care of it. THe problem was 2 Erick Ericksons. one was erick.erick...@gmail.com (that one had permissions), but that either isn't you, or was an old address. I put your new one in there and disabled access for the other one On Wed, Sep 5, 2012 at 12:59 PM, Steven A Rowe sar...@syr.edu wrote: Hi Erick, I think I can add you to the appropriate group. Trying now. Steve -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Wednesday, September 05, 2012 12:56 PM To: dev@lucene.apache.org Subject: Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source I'll be happy to. I got the patches and applied them, but I can't assign the JIRA to myself. I can in Solr, but in Lucene I don't have the assign tab displayed. Who do I talk to? Erick On Wed, Sep 5, 2012 at 11:57 AM, Robert Muir rcm...@gmail.com wrote: On Wed, Sep 5, 2012 at 11:04 AM, Erick Erickson erickerick...@gmail.com wrote: @Uwe: Right, wasn't thinking, a fairly common happening. Note that this is fairly ugly in that the simple-minded substitution I did isn't totally right. You get diff lines like: I think the automatic 2-space replacement is fine for hopeless files. I updated the patch on LUCENE-4362 with fixes for files that aren't hopeless, just have a few stray tabs. If you want, just assign the issue, but maybe apply that patch before doing anything automatic? I was careful with those files (some had tables etc that should be aligned). -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [jira] [Commented] (LUCENE-4362) ban tab-indented source
I added you also to Lucene! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Wednesday, September 05, 2012 6:56 PM To: dev@lucene.apache.org Subject: Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source I'll be happy to. I got the patches and applied them, but I can't assign the JIRA to myself. I can in Solr, but in Lucene I don't have the assign tab displayed. Who do I talk to? Erick On Wed, Sep 5, 2012 at 11:57 AM, Robert Muir rcm...@gmail.com wrote: On Wed, Sep 5, 2012 at 11:04 AM, Erick Erickson erickerick...@gmail.com wrote: @Uwe: Right, wasn't thinking, a fairly common happening. Note that this is fairly ugly in that the simple-minded substitution I did isn't totally right. You get diff lines like: I think the automatic 2-space replacement is fine for hopeless files. I updated the patch on LUCENE-4362 with fixes for files that aren't hopeless, just have a few stray tabs. If you want, just assign the issue, but maybe apply that patch before doing anything automatic? I was careful with those files (some had tables etc that should be aligned). -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [jira] [Commented] (LUCENE-4362) ban tab-indented source
LOL: I added that one because this was the Solr one. Erick: Just to be sure: what is your account name and eMail address in JIRA? - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Robert Muir [mailto:rcm...@gmail.com] Sent: Wednesday, September 05, 2012 7:02 PM To: dev@lucene.apache.org Subject: Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source I took care of it. THe problem was 2 Erick Ericksons. one was erick.erick...@gmail.com (that one had permissions), but that either isn't you, or was an old address. I put your new one in there and disabled access for the other one On Wed, Sep 5, 2012 at 12:59 PM, Steven A Rowe sar...@syr.edu wrote: Hi Erick, I think I can add you to the appropriate group. Trying now. Steve -Original Message- From: Erick Erickson [mailto:erickerick...@gmail.com] Sent: Wednesday, September 05, 2012 12:56 PM To: dev@lucene.apache.org Subject: Re: [jira] [Commented] (LUCENE-4362) ban tab-indented source I'll be happy to. I got the patches and applied them, but I can't assign the JIRA to myself. I can in Solr, but in Lucene I don't have the assign tab displayed. Who do I talk to? Erick On Wed, Sep 5, 2012 at 11:57 AM, Robert Muir rcm...@gmail.com wrote: On Wed, Sep 5, 2012 at 11:04 AM, Erick Erickson erickerick...@gmail.com wrote: @Uwe: Right, wasn't thinking, a fairly common happening. Note that this is fairly ugly in that the simple-minded substitution I did isn't totally right. You get diff lines like: I think the automatic 2-space replacement is fine for hopeless files. I updated the patch on LUCENE-4362 with fixes for files that aren't hopeless, just have a few stray tabs. If you want, just assign the issue, but maybe apply that patch before doing anything automatic? I was careful with those files (some had tables etc that should be aligned). -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- lucidworks.com - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4340) Move all codecs but Lucene40 to a module
[ https://issues.apache.org/jira/browse/LUCENE-4340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13448898#comment-13448898 ] Michael McCandless commented on LUCENE-4340: bq. I'm thinking of hardwiring HashFunction to MurmurHash2 +1 Move all codecs but Lucene40 to a module Key: LUCENE-4340 URL: https://issues.apache.org/jira/browse/LUCENE-4340 Project: Lucene - Core Issue Type: Task Components: core/codecs, general/build Reporter: Adrien Grand Fix For: 5.0, 4.0 Attachments: LUCENE-4340.patch, LUCENE-4340.patch, LUCENE-4340.sh We should move all concrete postings formats and codecs but Lucene40 to a module. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Linux (64bit/jdk1.7.0_07) - Build # 897 - Still Failing!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Linux/897/ Java: 64bit/jdk1.7.0_07 -XX:+UseSerialGC All tests passed Build Log: [...truncated 12045 lines...] check-licenses: [echo] License check under: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene [licenses] MISSING sha1 checksum file for: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/spatial/lib/spatial4j-0.3.jar [licenses] Scanned 19 JAR file(s) for licenses (in 0.24s.), 1 error(s). BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:64: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/build.xml:155: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/custom-tasks.xml:27: License check failed. Check the logs. Total time: 25 minutes 46 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 64bit/jdk1.7.0_07 -XX:+UseSerialGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS-MAVEN] Lucene-Solr-Maven-trunk #601: POMs out of sync
Build: https://builds.apache.org/job/Lucene-Solr-Maven-trunk/601/ No tests ran. Build Log: [...truncated 757 lines...] - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-Windows (32bit/jdk1.6.0_35) - Build # 630 - Failure!
Build: http://jenkins.sd-datasolutions.de/job/Lucene-Solr-trunk-Windows/630/ Java: 32bit/jdk1.6.0_35 -server -XX:+UseConcMarkSweepGC All tests passed Build Log: [...truncated 11459 lines...] check-licenses: [echo] License check under: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene [licenses] MISSING sha1 checksum file for: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\spatial\lib\spatial4j-0.3.jar [licenses] Scanned 19 JAR file(s) for licenses (in 0.42s.), 1 error(s). BUILD FAILED C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\build.xml:64: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\build.xml:155: The following error occurred while executing this line: C:\Jenkins\workspace\Lucene-Solr-trunk-Windows\lucene\tools\custom-tasks.xml:27: License check failed. Check the logs. Total time: 45 minutes 21 seconds Build step 'Invoke Ant' marked build as failure Recording test results Description set: Java: 32bit/jdk1.6.0_35 -server -XX:+UseConcMarkSweepGC Email was triggered for: Failure Sending email for trigger: Failure - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
