[jira] [Commented] (SOLR-5648) SolrCore#getStatistics() should nest open searchers' stats
[
https://issues.apache.org/jira/browse/SOLR-5648?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880795#comment-13880795
]
Shikhar Bhushan commented on SOLR-5648:
---
[~otis] yup
SolrCore#getStatistics() should nest open searchers' stats
--
Key: SOLR-5648
URL: https://issues.apache.org/jira/browse/SOLR-5648
Project: Solr
Issue Type: Task
Reporter: Shikhar Bhushan
Priority: Minor
Fix For: 4.7
Attachments: SOLR-5648.patch, oldestSearcherStaleness.gif,
openSearchers.gif
{{SolrIndexSearcher}} leaks are a notable cause of garbage collection issues
in codebases with custom components.
So it is useful to be able to access monitoring information about what
searchers are currently open, and in turn access their stats e.g.
{{openedAt}}.
This can be nested via {{SolrCore#getStatistics()}} which has a
{{_searchers}} collection of all open searchers.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[ https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-5477: --- Attachment: SOLR-5477.patch Another patch that has collection creation and split shard as async from OCP. Working on making other calls also async (which I think should be trivial and merely about calling the same methods). Working on storing/responding with better status for the status request. Right now, the status tracking is limited to : running/completed/failed/notfound. Async execution of OverseerCollectionProcessor tasks Key: SOLR-5477 URL: https://issues.apache.org/jira/browse/SOLR-5477 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Assignee: Anshum Gupta Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch Typical collection admin commands are long running and it is very common to have the requests get timed out. It is more of a problem if the cluster is very large.Add an option to run these commands asynchronously add an extra param async=true for all collection commands the task is written to ZK and the caller is returned a task id. as separate collection admin command will be added to poll the status of the task command=statusid=7657668909 if id is not passed all running async tasks should be listed A separate queue is created to store in-process tasks . After the tasks are completed the queue entry is removed. OverSeerColectionProcessor will perform these tasks in multiple threads -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[ https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880845#comment-13880845 ] Anshum Gupta edited comment on SOLR-5477 at 1/24/14 9:30 AM: - Another patch that has collection creation and split shard as async from OCP. Working on making other calls also async (which I think should be trivial and merely about calling the same methods). Working on storing/responding with better status for the status request. Right now, the status tracking is limited to : running/completed/failed/notfound. Also, trying to get another patch that saves information in zk instead of in-memory for CoreAdmin request state. was (Author: anshumg): Another patch that has collection creation and split shard as async from OCP. Working on making other calls also async (which I think should be trivial and merely about calling the same methods). Working on storing/responding with better status for the status request. Right now, the status tracking is limited to : running/completed/failed/notfound. Async execution of OverseerCollectionProcessor tasks Key: SOLR-5477 URL: https://issues.apache.org/jira/browse/SOLR-5477 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Assignee: Anshum Gupta Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch Typical collection admin commands are long running and it is very common to have the requests get timed out. It is more of a problem if the cluster is very large.Add an option to run these commands asynchronously add an extra param async=true for all collection commands the task is written to ZK and the caller is returned a task id. as separate collection admin command will be added to poll the status of the task command=statusid=7657668909 if id is not passed all running async tasks should be listed A separate queue is created to store in-process tasks . After the tasks are completed the queue entry is removed. OverSeerColectionProcessor will perform these tasks in multiple threads -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5661) PriorityQueue has OOM (Requested array size exceeds VM limit) issue
Raintung Li created SOLR-5661: - Summary: PriorityQueue has OOM (Requested array size exceeds VM limit) issue Key: SOLR-5661 URL: https://issues.apache.org/jira/browse/SOLR-5661 Project: Solr Issue Type: Bug Components: contrib - Solr Cell (Tika extraction) Affects Versions: 4.6, 4.5.1, 4.5, 4.4, 4.3.1 Environment: JDK 7 Reporter: Raintung Li It look like JDK7 change the design for max_array_length logic, it isn't max_jint, and it should be max_jint - header_size(type). If you deliver the Integer.MaxValue to create the PriorityQueue and have enough memory, you will find it is ok in JVM6 but not work in JVM7. JVM7 will throw OOM error while do array rang checking. It should the compatible issue between JVM6 and JVM7. Maybe need protect in the code logic, throw OOM look like big issues for customer. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5661) PriorityQueue has OOM (Requested array size exceeds VM limit) issue
[ https://issues.apache.org/jira/browse/SOLR-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880869#comment-13880869 ] Michael McCandless commented on SOLR-5661: -- Hmm, how were you able to get an OOME from Solr? Lucene's IndexSearcher tries to prevent this, when you ask for Integer.MAX_VALUE as the topN hits to the search method, it drops that to the maxDoc for the reader. Still, we should fix oal.util.PriorityQueue to use ArrayUtil.MAX_ARRAY_LENGTH, not Integer.MAX_VALUE. PriorityQueue has OOM (Requested array size exceeds VM limit) issue --- Key: SOLR-5661 URL: https://issues.apache.org/jira/browse/SOLR-5661 Project: Solr Issue Type: Bug Components: contrib - Solr Cell (Tika extraction) Affects Versions: 4.3.1, 4.4, 4.5, 4.5.1, 4.6 Environment: JDK 7 Reporter: Raintung Li It look like JDK7 change the design for max_array_length logic, it isn't max_jint, and it should be max_jint - header_size(type). If you deliver the Integer.MaxValue to create the PriorityQueue and have enough memory, you will find it is ok in JVM6 but not work in JVM7. JVM7 will throw OOM error while do array rang checking. It should the compatible issue between JVM6 and JVM7. Maybe need protect in the code logic, throw OOM look like big issues for customer. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5662) {!parent} parser with scoreMode
Moritz Munte created SOLR-5662:
--
Summary: {!parent} parser with scoreMode
Key: SOLR-5662
URL: https://issues.apache.org/jira/browse/SOLR-5662
Project: Solr
Issue Type: Improvement
Affects Versions: 4.6
Reporter: Moritz Munte
Priority: Minor
ToParentBlockJoinQuery has support for different score modes, but {!parent}
parser has None mode hardcoded without an option to change it.
It would be usefull if there is a parameter to change the score mode or set a
reasonable default.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5409) ToParentBlockJoinCollector.getTopGroups returns empty Groups
[ https://issues.apache.org/jira/browse/LUCENE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880890#comment-13880890 ] Michael McCandless commented on LUCENE-5409: Interesting ... because the hashCode for the TermQuery and the BooleanQuery do in fact differ. OK I see what's happening: ToParentBJQ.hashCode uses *origChildQuery* to compute its hashcode (and in .equals); so ... rewrite won't change it, by design. Hmm, which then seems like you should not be hitting an issue here? Maybe try to boil down your problem to a small test case? ToParentBlockJoinCollector.getTopGroups returns empty Groups Key: LUCENE-5409 URL: https://issues.apache.org/jira/browse/LUCENE-5409 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.6 Environment: Ubuntu 12.04 Reporter: Peng Cheng Assignee: Michael McCandless Priority: Critical Fix For: 4.7 Original Estimate: 168h Remaining Estimate: 168h A bug is observed to cause unstable results returned by the getTopGroups function of class ToParentBlockJoinCollector. In the scorer generation stage, the ToParentBlockJoinCollector will automatically rewrite all the associated ToParentBlockJoinQuery (and their subqueries), and save them into its in-memory Look-up table, namely joinQueryID (see enroll() method for detail). Unfortunately, in the getTopGroups method, the new ToParentBlockJoinQuery parameter is not rewritten (at least users are not expected to do so). When the new one is searched in the old lookup table (considering the impact of rewrite() on hashCode()), the lookup will largely fail and eventually end up with a topGroup collection consisting of only empty groups (their hitCounts are guaranteed to be zero). An easy fix would be to rewrite the original BlockJoinQuery before invoking getTopGroups method. However, the computational cost of this is not optimal. A better but slightly more complex solution would be to save unrewrited Queries into the lookup table. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC4
+1 SUCCESS! [0:38:05.694111] Mike McCandless http://blog.mikemccandless.com On Fri, Jan 24, 2014 at 1:26 AM, Robert Muir rcm...@gmail.com wrote: +1 Please pay close attention to Mark's followup email! Load release URL http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/;... ... SUCCESS! [0:38:51.100830] On Thu, Jan 23, 2014 at 10:26 PM, Mark Miller markrmil...@gmail.com wrote: Sorry - watch out for that link - I’m seeing the text correctly, but the underlying link incorrectly when I look at it in my send folder. The evils of html mail I guess. To be sure you have the right artifacts, make sure you are looking at the following location: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ - Mark On Jan 23, 2014, at 9:57 PM, Mark Miller markrmil...@gmail.com wrote: Here we go, hopefully for that last time now…thanks everyone for bearing with us. Please vote to release the following artifacts: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ Here is my +1. SUCCESS! [0:56:37.409716] -- - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5376) Add a demo search server
[ https://issues.apache.org/jira/browse/LUCENE-5376?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13880906#comment-13880906 ] ASF subversion and git services commented on LUCENE-5376: - Commit 1560946 from [~mikemccand] in branch 'dev/branches/lucene5376' [ https://svn.apache.org/r1560946 ] LUCENE-5376: improve comments / nocommits Add a demo search server Key: LUCENE-5376 URL: https://issues.apache.org/jira/browse/LUCENE-5376 Project: Lucene - Core Issue Type: Improvement Reporter: Michael McCandless Assignee: Michael McCandless Attachments: lucene-demo-server.tgz I think it'd be useful to have a demo search server for Lucene. Rather than being fully featured, like Solr, it would be minimal, just wrapping the existing Lucene modules to show how you can make use of these features in a server setting. The purpose is to demonstrate how one can build a minimal search server on top of APIs like SearchManager, SearcherLifetimeManager, etc. This is also useful for finding rough edges / issues in Lucene's APIs that make building a server unnecessarily hard. I don't think it should have back compatibility promises (except Lucene's index back compatibility), so it's free to improve as Lucene's APIs change. As a starting point, I'll post what I built for the eating your own dog food search app for Lucene's Solr's jira issues http://jirasearch.mikemccandless.com (blog: http://blog.mikemccandless.com/2013/05/eating-dog-food-with-lucene.html ). It uses Netty to expose basic indexing searching APIs via JSON, but it's very rough (lots nocommits). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5473) Make one state.json per collection
[ https://issues.apache.org/jira/browse/SOLR-5473?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-5473: - Attachment: SOLR-5473.patch Make one state.json per collection -- Key: SOLR-5473 URL: https://issues.apache.org/jira/browse/SOLR-5473 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Assignee: Noble Paul Attachments: SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch, SOLR-5473.patch As defined in the parent issue, store the states of each collection under /collections/collectionname/state.json node -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC4
+1 $ python3.2 -u dev-tools/scripts/smokeTestRelease.py http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ 1560866 4.6.1 /tmp/smoke_test_4_6_1 ... SUCCESS! [0:59:34.337150] On Fri, Jan 24, 2014 at 12:03 PM, Michael McCandless luc...@mikemccandless.com wrote: +1 SUCCESS! [0:38:05.694111] Mike McCandless http://blog.mikemccandless.com On Fri, Jan 24, 2014 at 1:26 AM, Robert Muir rcm...@gmail.com wrote: +1 Please pay close attention to Mark's followup email! Load release URL http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/;... ... SUCCESS! [0:38:51.100830] On Thu, Jan 23, 2014 at 10:26 PM, Mark Miller markrmil...@gmail.com wrote: Sorry - watch out for that link - I’m seeing the text correctly, but the underlying link incorrectly when I look at it in my send folder. The evils of html mail I guess. To be sure you have the right artifacts, make sure you are looking at the following location: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ - Mark On Jan 23, 2014, at 9:57 PM, Mark Miller markrmil...@gmail.com wrote: Here we go, hopefully for that last time now…thanks everyone for bearing with us. Please vote to release the following artifacts: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ Here is my +1. SUCCESS! [0:56:37.409716] -- - Mark - 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] (SOLR-5663) example-DIH uses non-existing column in query
Stefan Matheis (steffkes) created SOLR-5663:
---
Summary: example-DIH uses non-existing column in query
Key: SOLR-5663
URL: https://issues.apache.org/jira/browse/SOLR-5663
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 4.6, 4.5, 4.4, 4.3, 4.2, 4.1, 4.0
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 5.0, 4.7
mavroprovato mentioned on IRC that the example-DIH configuration wouldn't
import values for the {{cat}} field.
looking at the configuration .. the query and the mapping are use the name in
different cases (lower vs. upper) which does not work.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5663) example-DIH uses non-existing column for mapping (case-sensitive)
[
https://issues.apache.org/jira/browse/SOLR-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-5663:
Summary: example-DIH uses non-existing column for mapping (case-sensitive)
(was: example-DIH uses non-existing column in query)
example-DIH uses non-existing column for mapping (case-sensitive)
-
Key: SOLR-5663
URL: https://issues.apache.org/jira/browse/SOLR-5663
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 5.0, 4.7
Attachments: SOLR-5663.patch
mavroprovato mentioned on IRC that the example-DIH configuration wouldn't
import values for the {{cat}} field.
looking at the configuration .. the query and the mapping are use the name in
different cases (lower vs. upper) which does not work.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5663) example-DIH uses non-existing column for mapping (case-sensitive)
[
https://issues.apache.org/jira/browse/SOLR-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-5663:
Attachment: SOLR-5663.patch
example-DIH uses non-existing column for mapping (case-sensitive)
-
Key: SOLR-5663
URL: https://issues.apache.org/jira/browse/SOLR-5663
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 5.0, 4.7
Attachments: SOLR-5663.patch
mavroprovato mentioned on IRC that the example-DIH configuration wouldn't
import values for the {{cat}} field.
looking at the configuration .. the query and the mapping are use the name in
different cases (lower vs. upper) which does not work.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5663) example-DIH uses non-existing column for mapping (case-sensitive)
[
https://issues.apache.org/jira/browse/SOLR-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881019#comment-13881019
]
ASF subversion and git services commented on SOLR-5663:
---
Commit 1561026 from [~steffkes] in branch 'dev/trunk'
[ https://svn.apache.org/r1561026 ]
SOLR-5663: example-DIH uses non-existing column for mapping (case-sensitive)
example-DIH uses non-existing column for mapping (case-sensitive)
-
Key: SOLR-5663
URL: https://issues.apache.org/jira/browse/SOLR-5663
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 5.0, 4.7
Attachments: SOLR-5663.patch
mavroprovato mentioned on IRC that the example-DIH configuration wouldn't
import values for the {{cat}} field.
looking at the configuration .. the query and the mapping are use the name in
different cases (lower vs. upper) which does not work.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5663) example-DIH uses non-existing column for mapping (case-sensitive)
[
https://issues.apache.org/jira/browse/SOLR-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881026#comment-13881026
]
ASF subversion and git services commented on SOLR-5663:
---
Commit 1561029 from [~steffkes] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1561029 ]
SOLR-5663: example-DIH uses non-existing column for mapping (case-sensitive)
(merge r1561026)
example-DIH uses non-existing column for mapping (case-sensitive)
-
Key: SOLR-5663
URL: https://issues.apache.org/jira/browse/SOLR-5663
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 5.0, 4.7
Attachments: SOLR-5663.patch
mavroprovato mentioned on IRC that the example-DIH configuration wouldn't
import values for the {{cat}} field.
looking at the configuration .. the query and the mapping are use the name in
different cases (lower vs. upper) which does not work.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5663) example-DIH uses non-existing column for mapping (case-sensitive)
[
https://issues.apache.org/jira/browse/SOLR-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) resolved SOLR-5663.
-
Resolution: Fixed
example-DIH uses non-existing column for mapping (case-sensitive)
-
Key: SOLR-5663
URL: https://issues.apache.org/jira/browse/SOLR-5663
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 5.0, 4.7
Attachments: SOLR-5663.patch
mavroprovato mentioned on IRC that the example-DIH configuration wouldn't
import values for the {{cat}} field.
looking at the configuration .. the query and the mapping are use the name in
different cases (lower vs. upper) which does not work.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC4
+1 Smoketester is happy. On Fri, Jan 24, 2014 at 3:28 PM, Simon Willnauer simon.willna...@gmail.com wrote: +1 $ python3.2 -u dev-tools/scripts/smokeTestRelease.py http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ 1560866 4.6.1 /tmp/smoke_test_4_6_1 ... SUCCESS! [0:59:34.337150] On Fri, Jan 24, 2014 at 12:03 PM, Michael McCandless luc...@mikemccandless.com wrote: +1 SUCCESS! [0:38:05.694111] Mike McCandless http://blog.mikemccandless.com On Fri, Jan 24, 2014 at 1:26 AM, Robert Muir rcm...@gmail.com wrote: +1 Please pay close attention to Mark's followup email! Load release URL http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/;... ... SUCCESS! [0:38:51.100830] On Thu, Jan 23, 2014 at 10:26 PM, Mark Miller markrmil...@gmail.com wrote: Sorry - watch out for that link - I’m seeing the text correctly, but the underlying link incorrectly when I look at it in my send folder. The evils of html mail I guess. To be sure you have the right artifacts, make sure you are looking at the following location: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ - Mark On Jan 23, 2014, at 9:57 PM, Mark Miller markrmil...@gmail.com wrote: Here we go, hopefully for that last time now…thanks everyone for bearing with us. Please vote to release the following artifacts: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ Here is my +1. SUCCESS! [0:56:37.409716] -- - Mark - 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 -- Adrien - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Areek Zillur as Lucene/Solr committer!
Welcome Areek! On 23 January 2014 01:39, Koji Sekiguchi k...@r.email.ne.jp wrote: Welcome, Areek! koji -- http://soleami.com/blog/mahout-and-machine-learning- training-course-is-here.html (14/01/22 4:26), Robert Muir wrote: I'm pleased to announce that Areek Zillur has accepted to join our ranks as a committer. Areek has been improving suggester support in Lucene and Solr, including a revamped Solr component slated for the 4.7 release. [1] Areek, it is tradition that you introduce yourself with a brief bio. Once your account is setup, you should then be able to add yourself to the who we are page on the website as well. Congratulations and welcome! [1] https://issues.apache.org/jira/browse/SOLR-5378 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org -- Met vriendelijke groet, Martijn van Groningen
[jira] [Commented] (SOLR-5663) example-DIH uses non-existing column for mapping (case-sensitive)
[
https://issues.apache.org/jira/browse/SOLR-5663?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881055#comment-13881055
]
Shalin Shekhar Mangar commented on SOLR-5663:
-
This shouldn't be required, right? The column names are supposed to be case
insensitive. For example, see TestDocBuilder2.testSingleEntity_CaseInsensitive()
example-DIH uses non-existing column for mapping (case-sensitive)
-
Key: SOLR-5663
URL: https://issues.apache.org/jira/browse/SOLR-5663
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 4.0, 4.1, 4.2, 4.3, 4.4, 4.5, 4.6
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 5.0, 4.7
Attachments: SOLR-5663.patch
mavroprovato mentioned on IRC that the example-DIH configuration wouldn't
import values for the {{cat}} field.
looking at the configuration .. the query and the mapping are use the name in
different cases (lower vs. upper) which does not work.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] Release Lucene/Solr 4.6.1 RC4
+1 to release! thetaphi@opteron:~$ JAVA_HOME=$HOME/jdk1.6.0_45 JAVA6_HOME=$JAVA_HOME JAVA7_HOME=$HOME/jdk1.7.0_25 python3.2 -u dev-tools/scripts/smokeTestRelease.py 'http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/' 1560866 4.6.1 ~/tmp/ SUCCESS! [1:44:56.197125] I also pointed my local Maven Config to the 2 maven folders (as separate, file-based repository) and was able to compile some apps with 4.6.1 as version number. Smoke tester is happy! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Adrien Grand [mailto:jpou...@gmail.com] Sent: Friday, January 24, 2014 4:12 PM To: dev@lucene.apache.org Subject: Re: [VOTE] Release Lucene/Solr 4.6.1 RC4 +1 Smoketester is happy. On Fri, Jan 24, 2014 at 3:28 PM, Simon Willnauer simon.willna...@gmail.com wrote: +1 $ python3.2 -u dev-tools/scripts/smokeTestRelease.py http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ 1560866 4.6.1 /tmp/smoke_test_4_6_1 ... SUCCESS! [0:59:34.337150] On Fri, Jan 24, 2014 at 12:03 PM, Michael McCandless luc...@mikemccandless.com wrote: +1 SUCCESS! [0:38:05.694111] Mike McCandless http://blog.mikemccandless.com On Fri, Jan 24, 2014 at 1:26 AM, Robert Muir rcm...@gmail.com wrote: +1 Please pay close attention to Mark's followup email! Load release URL http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/;... ... SUCCESS! [0:38:51.100830] On Thu, Jan 23, 2014 at 10:26 PM, Mark Miller markrmil...@gmail.com wrote: Sorry - watch out for that link - I’m seeing the text correctly, but the underlying link incorrectly when I look at it in my send folder. The evils of html mail I guess. To be sure you have the right artifacts, make sure you are looking at the following location: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ - Mark On Jan 23, 2014, at 9:57 PM, Mark Miller markrmil...@gmail.com wrote: Here we go, hopefully for that last time now…thanks everyone for bearing with us. Please vote to release the following artifacts: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ Here is my +1. SUCCESS! [0:56:37.409716] -- - Mark - 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 -- Adrien - 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] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[ https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881093#comment-13881093 ] Anshum Gupta commented on SOLR-5477: I had a discussion with Noble (offline) and we thought that holding this stuff for persistence in zk didn't make much sense. Here are the reasons: * Every request would need to de-duplicate against the submitted/completed/failed tasks and zk queues aren't fit for that. Every dedup would translate to fetching all children and running a compare or something. With all cores trying to use the same zk setup, not sure if it's even required. In memory hashes would work better at handling this use case. * We may not be interested in persistence of results over a longer duration i.e. if the node goes down, we should be fine with losing the request information as in general, the time taken to bring the same node back up would be more than someone else doing the job in the meanwhile (fair assumption?). Async execution of OverseerCollectionProcessor tasks Key: SOLR-5477 URL: https://issues.apache.org/jira/browse/SOLR-5477 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Assignee: Anshum Gupta Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch Typical collection admin commands are long running and it is very common to have the requests get timed out. It is more of a problem if the cluster is very large.Add an option to run these commands asynchronously add an extra param async=true for all collection commands the task is written to ZK and the caller is returned a task id. as separate collection admin command will be added to poll the status of the task command=statusid=7657668909 if id is not passed all running async tasks should be listed A separate queue is created to store in-process tasks . After the tasks are completed the queue entry is removed. OverSeerColectionProcessor will perform these tasks in multiple threads -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
RE: [VOTE] Release Lucene/Solr 4.6.1 RC4
Hi, +1 to release! thetaphi@opteron:~$ JAVA_HOME=$HOME/jdk1.6.0_45 JAVA6_HOME=$JAVA_HOME JAVA7_HOME=$HOME/jdk1.7.0_25 python3.2 -u dev-tools/scripts/smokeTestRelease.py 'http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/' 1560866 4.6.1 ~/tmp/ SUCCESS! [1:44:56.197125] I also pointed my local Maven Config to the 2 maven folders (as separate, file-based repository) and was able to compile some apps with 4.6.1 as version number. FYI, this is how this could be done in your pom.xml: repositories repository idmy-lucene/id nameApache Lucene RC repo/name urlhttp://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/solr/maven//url /repository repository idmy-solr/id nameApache Solr RC repo/name urlhttp://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/lucene/maven//url /repository /repositories Be sure to nuke those repos and delete the maven cache, too (especially if we respin!!!), once Lucene is released. BTW, it would be a lot easier, if Lucene+Solr would share the same maven target folder when building artifacts! Some directory layout on the staging website like: lucene/ solr/ maven/ Uwe Smoke tester is happy! - Uwe Schindler H.-H.-Meier-Allee 63, D-28213 Bremen http://www.thetaphi.de eMail: u...@thetaphi.de -Original Message- From: Adrien Grand [mailto:jpou...@gmail.com] Sent: Friday, January 24, 2014 4:12 PM To: dev@lucene.apache.org Subject: Re: [VOTE] Release Lucene/Solr 4.6.1 RC4 +1 Smoketester is happy. On Fri, Jan 24, 2014 at 3:28 PM, Simon Willnauer simon.willna...@gmail.com wrote: +1 $ python3.2 -u dev-tools/scripts/smokeTestRelease.py http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ 1560866 4.6.1 /tmp/smoke_test_4_6_1 ... SUCCESS! [0:59:34.337150] On Fri, Jan 24, 2014 at 12:03 PM, Michael McCandless luc...@mikemccandless.com wrote: +1 SUCCESS! [0:38:05.694111] Mike McCandless http://blog.mikemccandless.com On Fri, Jan 24, 2014 at 1:26 AM, Robert Muir rcm...@gmail.com wrote: +1 Please pay close attention to Mark's followup email! Load release URL http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/;... ... SUCCESS! [0:38:51.100830] On Thu, Jan 23, 2014 at 10:26 PM, Mark Miller markrmil...@gmail.com wrote: Sorry - watch out for that link - I’m seeing the text correctly, but the underlying link incorrectly when I look at it in my send folder. The evils of html mail I guess. To be sure you have the right artifacts, make sure you are looking at the following location: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ - Mark On Jan 23, 2014, at 9:57 PM, Mark Miller markrmil...@gmail.com wrote: Here we go, hopefully for that last time now…thanks everyone for bearing with us. Please vote to release the following artifacts: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ Here is my +1. SUCCESS! [0:56:37.409716] -- - Mark --- -- 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 -- Adrien - 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] [Updated] (LUCENE-5415) Support wildcard co in PostingsHighlighter
[ https://issues.apache.org/jira/browse/LUCENE-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5415: Attachment: LUCENE-5415.patch Here's a prototype. just has one trivial test (needs some more before committing), so the usual warnings apply. But it does not change the default behavior at all, or require any changes to the main loop of the highlighting algorithm. Support wildcard co in PostingsHighlighter Key: LUCENE-5415 URL: https://issues.apache.org/jira/browse/LUCENE-5415 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Reporter: Robert Muir Attachments: LUCENE-5415.patch PostingsHighlighter uses the offsets encoded in the postings lists for the terms to find query matches. As such, it isn't really suitable for stuff like wildcards for two reasons: 1. an expensive rewrite against the term dictionary (i think other highlighters share this problem) 2. accumulating data from potentially many terms (e.g. reading many postings) However, we could provide an option for some of these queries to work, but in a different way, that avoids these downsides. Instead we can just grab the Automaton representation of the queries, and match it against the content directly (which won't blow up). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5488) Fix up test failures for Analytics Component
[ https://issues.apache.org/jira/browse/SOLR-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Bower updated SOLR-5488: --- Attachment: SOLR-5488.patch New patch.. your test failures led me to one issue with MinMax collector where it was checking if the stat was max but checking min != null... Fix up test failures for Analytics Component Key: SOLR-5488 URL: https://issues.apache.org/jira/browse/SOLR-5488 Project: Solr Issue Type: Bug Affects Versions: 5.0, 4.7 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch The analytics component has a few test failures, perhaps environment-dependent. This is just to collect the test fixes in one place for convenience when we merge back into 4.x -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5638) Collection creation partially works, but results in unusable configuration due to missing config in ZK
[ https://issues.apache.org/jira/browse/SOLR-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Molloy updated SOLR-5638: --- Attachment: SOLR-5638.patch This patch simply unloads the core after failure so that discovery mechanism doesn't try to reload it. Probably not the best solution but seems to work for scenarios I've faced so far. Collection creation partially works, but results in unusable configuration due to missing config in ZK -- Key: SOLR-5638 URL: https://issues.apache.org/jira/browse/SOLR-5638 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.6 Reporter: Nathan Neulinger Attachments: SOLR-5638.patch Need help properly recovering from 'collection gets created without config being defined'. Right now, if you submit a collection create and the config is missing, it will proceed with partially creating cores, but then the cores fail to load. This requires manual intervention on the server to fix unless you pick a new colllection name: What's worse - if you retry the create a second time, it will usually try to create the replicas in the opposite order, resulting in TWO broken cores on each box, one for each attempted replica. beta1-newarch_hive1_v12_shard1_replica1: org.apache.solr.common.cloud.ZooKeeperException:org.apache.solr.common.cloud.ZooKeeperException: Specified config does not exist in ZooKeeper:hivepoint-unknown beta1-newarch_hive1_v12_shard1_replica2: org.apache.solr.common.cloud.ZooKeeperException:org.apache.solr.common.cloud.ZooKeeperException: Specified config does not exist in ZooKeeper:hivepoint-unknown I already know how to clear this up manually, but this is something where solr is allowing a condition in external service to result in a corrupted/partial configuration. I can see an easy option for resolving this as a workaround - allow a collection CREATE operation to specify reuseCores - i.e. allow it to use an existing core of the proper name if it already exists. Right now you wind up getting: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error CREATEing SolrCore 'beta1-newarch_hive1_v12_shard1_replica1': Could not create a new core in solr/beta1-newarch_hive1_v12_shard1_replica1/as another core is already defined there org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error CREATEing SolrCore 'beta1-newarch_hive1_v12_shard1_replica2': Could not create a new core in solr/beta1-newarch_hive1_v12_shard1_replica2/as another core is already defined there -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5415) Support wildcard co in PostingsHighlighter
Robert Muir created LUCENE-5415: --- Summary: Support wildcard co in PostingsHighlighter Key: LUCENE-5415 URL: https://issues.apache.org/jira/browse/LUCENE-5415 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Reporter: Robert Muir PostingsHighlighter uses the offsets encoded in the postings lists for the terms to find query matches. As such, it isn't really suitable for stuff like wildcards for two reasons: 1. an expensive rewrite against the term dictionary (i think other highlighters share this problem) 2. accumulating data from potentially many terms (e.g. reading many postings) However, we could provide an option for some of these queries to work, but in a different way, that avoids these downsides. Instead we can just grab the Automaton representation of the queries, and match it against the content directly (which won't blow up). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5638) Collection creation partially works, but results in unusable configuration due to missing config in ZK
[ https://issues.apache.org/jira/browse/SOLR-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881127#comment-13881127 ] Mark Miller commented on SOLR-5638: --- We should fail fast if the config does not exist - avoid even trying to create those cores. This can probably happen in other scenarios as well though, so probably a good idea to consider Steve's approach as well. Collection creation partially works, but results in unusable configuration due to missing config in ZK -- Key: SOLR-5638 URL: https://issues.apache.org/jira/browse/SOLR-5638 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.6 Reporter: Nathan Neulinger Attachments: SOLR-5638.patch Need help properly recovering from 'collection gets created without config being defined'. Right now, if you submit a collection create and the config is missing, it will proceed with partially creating cores, but then the cores fail to load. This requires manual intervention on the server to fix unless you pick a new colllection name: What's worse - if you retry the create a second time, it will usually try to create the replicas in the opposite order, resulting in TWO broken cores on each box, one for each attempted replica. beta1-newarch_hive1_v12_shard1_replica1: org.apache.solr.common.cloud.ZooKeeperException:org.apache.solr.common.cloud.ZooKeeperException: Specified config does not exist in ZooKeeper:hivepoint-unknown beta1-newarch_hive1_v12_shard1_replica2: org.apache.solr.common.cloud.ZooKeeperException:org.apache.solr.common.cloud.ZooKeeperException: Specified config does not exist in ZooKeeper:hivepoint-unknown I already know how to clear this up manually, but this is something where solr is allowing a condition in external service to result in a corrupted/partial configuration. I can see an easy option for resolving this as a workaround - allow a collection CREATE operation to specify reuseCores - i.e. allow it to use an existing core of the proper name if it already exists. Right now you wind up getting: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error CREATEing SolrCore 'beta1-newarch_hive1_v12_shard1_replica1': Could not create a new core in solr/beta1-newarch_hive1_v12_shard1_replica1/as another core is already defined there org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error CREATEing SolrCore 'beta1-newarch_hive1_v12_shard1_replica2': Could not create a new core in solr/beta1-newarch_hive1_v12_shard1_replica2/as another core is already defined there -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5638) Collection creation partially works, but results in unusable configuration due to missing config in ZK
[ https://issues.apache.org/jira/browse/SOLR-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881131#comment-13881131 ] Nathan Neulinger commented on SOLR-5638: Will the unload result the core still being on the disk - just not loaded? In which case, what happens when the create collection is requested again and it decides to lay out the replicas in the other order? Collection creation partially works, but results in unusable configuration due to missing config in ZK -- Key: SOLR-5638 URL: https://issues.apache.org/jira/browse/SOLR-5638 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.6 Reporter: Nathan Neulinger Attachments: SOLR-5638.patch Need help properly recovering from 'collection gets created without config being defined'. Right now, if you submit a collection create and the config is missing, it will proceed with partially creating cores, but then the cores fail to load. This requires manual intervention on the server to fix unless you pick a new colllection name: What's worse - if you retry the create a second time, it will usually try to create the replicas in the opposite order, resulting in TWO broken cores on each box, one for each attempted replica. beta1-newarch_hive1_v12_shard1_replica1: org.apache.solr.common.cloud.ZooKeeperException:org.apache.solr.common.cloud.ZooKeeperException: Specified config does not exist in ZooKeeper:hivepoint-unknown beta1-newarch_hive1_v12_shard1_replica2: org.apache.solr.common.cloud.ZooKeeperException:org.apache.solr.common.cloud.ZooKeeperException: Specified config does not exist in ZooKeeper:hivepoint-unknown I already know how to clear this up manually, but this is something where solr is allowing a condition in external service to result in a corrupted/partial configuration. I can see an easy option for resolving this as a workaround - allow a collection CREATE operation to specify reuseCores - i.e. allow it to use an existing core of the proper name if it already exists. Right now you wind up getting: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error CREATEing SolrCore 'beta1-newarch_hive1_v12_shard1_replica1': Could not create a new core in solr/beta1-newarch_hive1_v12_shard1_replica1/as another core is already defined there org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error CREATEing SolrCore 'beta1-newarch_hive1_v12_shard1_replica2': Could not create a new core in solr/beta1-newarch_hive1_v12_shard1_replica2/as another core is already defined there -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[ https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881153#comment-13881153 ] Shalin Shekhar Mangar commented on SOLR-5477: - I don't understand why we are using DistributedQueues for holding status in the first place. It is just not required. We should just have a zk node constructed with a prefix and user specified hash for holding status. Async execution of OverseerCollectionProcessor tasks Key: SOLR-5477 URL: https://issues.apache.org/jira/browse/SOLR-5477 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Assignee: Anshum Gupta Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch Typical collection admin commands are long running and it is very common to have the requests get timed out. It is more of a problem if the cluster is very large.Add an option to run these commands asynchronously add an extra param async=true for all collection commands the task is written to ZK and the caller is returned a task id. as separate collection admin command will be added to poll the status of the task command=statusid=7657668909 if id is not passed all running async tasks should be listed A separate queue is created to store in-process tasks . After the tasks are completed the queue entry is removed. OverSeerColectionProcessor will perform these tasks in multiple threads -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5367) NoSuchElementException occurs when org.apache.lucene.facet.index.FacetFields is used.
[
https://issues.apache.org/jira/browse/LUCENE-5367?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881161#comment-13881161
]
Ying Andrews commented on LUCENE-5367:
--
Hi Shai,
I am experiencing the same issue with Lucene 4.4. Will this issue go away if I
upgrade to Lucene 4.6 (the latest release as of today.) Or should I grab the
code from 4.7 branch and try out myself?
Thank you very much for your time and effort.
Ying
NoSuchElementException occurs when org.apache.lucene.facet.index.FacetFields
is used.
-
Key: LUCENE-5367
URL: https://issues.apache.org/jira/browse/LUCENE-5367
Project: Lucene - Core
Issue Type: Bug
Components: modules/facet
Affects Versions: 4.2.1, 4.6
Reporter: Lucien Pereira
Priority: Blocker
Hi,
When I use the API as below :
{code}
ListCategoryPath categories = Collections.CategoryPathsingletonList(new
CategoryPath(path.toArray(new String[path.size()])));
FacetFields facetFields = new FacetFields(taxonomyWriter);
facetFields.addFields(document, categories);
taxonomyWriter.commit();
{code}
An exception occurs :
{quote}
java.util.NoSuchElementException
at java.util.Collections$1.next(Collections.java:3302)
at
org.apache.lucene.facet.index.DrillDownStream.reset(DrillDownStream.java:78)
at
org.apache.lucene.index.DocInverterPerField.processFields(DocInverterPerField.java:97)
at
org.apache.lucene.index.DocFieldProcessor.processDocument(DocFieldProcessor.java:248)
at
org.apache.lucene.index.DocumentsWriterPerThread.updateDocument(DocumentsWriterPerThread.java:253)
at
org.apache.lucene.index.DocumentsWriter.updateDocument(DocumentsWriter.java:453)
at
org.apache.lucene.index.IndexWriter.updateDocument(IndexWriter.java:1520)
at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1190)
at
org.apache.lucene.index.IndexWriter.addDocument(IndexWriter.java:1171)
{quote}
Seems likes this is due to multiple calls to
org.apache.lucene.facet.index.DrillDownStream#reset which invoques #next() on
an 'used' iterator.
Regards,
Lucien
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5625) Add to testing for SolrCmdDistributor
[ https://issues.apache.org/jira/browse/SOLR-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881168#comment-13881168 ] ASF subversion and git services commented on SOLR-5625: --- Commit 1561077 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1561077 ] SOLR-5625: Add testing around SolrCmdDistributor Add to testing for SolrCmdDistributor - Key: SOLR-5625 URL: https://issues.apache.org/jira/browse/SOLR-5625 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[ https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881166#comment-13881166 ] Shalin Shekhar Mangar commented on SOLR-5477: - Just to clarify, I'm not against storing status for core admin tasks in memory but just wanted to point out that problem of deduping by getting all children is a problem that we're creating ourselves by (ab)using DQ. Async execution of OverseerCollectionProcessor tasks Key: SOLR-5477 URL: https://issues.apache.org/jira/browse/SOLR-5477 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Assignee: Anshum Gupta Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch Typical collection admin commands are long running and it is very common to have the requests get timed out. It is more of a problem if the cluster is very large.Add an option to run these commands asynchronously add an extra param async=true for all collection commands the task is written to ZK and the caller is returned a task id. as separate collection admin command will be added to poll the status of the task command=statusid=7657668909 if id is not passed all running async tasks should be listed A separate queue is created to store in-process tasks . After the tasks are completed the queue entry is removed. OverSeerColectionProcessor will perform these tasks in multiple threads -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5625) Add to testing for SolrCmdDistributor
[ https://issues.apache.org/jira/browse/SOLR-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-5625. --- Resolution: Fixed Add to testing for SolrCmdDistributor - Key: SOLR-5625 URL: https://issues.apache.org/jira/browse/SOLR-5625 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5625) Add to testing for SolrCmdDistributor
[ https://issues.apache.org/jira/browse/SOLR-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881176#comment-13881176 ] ASF subversion and git services commented on SOLR-5625: --- Commit 1561081 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1561081 ] SOLR-5625: Add testing around SolrCmdDistributor Add to testing for SolrCmdDistributor - Key: SOLR-5625 URL: https://issues.apache.org/jira/browse/SOLR-5625 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5345) OpenCloseCoreStressTest opens too many files (causing it to fail often)
[ https://issues.apache.org/jira/browse/SOLR-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-5345. --- Resolution: Fixed I haven not seen this in a long time, including in nightly runs that I do. OpenCloseCoreStressTest opens too many files (causing it to fail often) --- Key: SOLR-5345 URL: https://issues.apache.org/jira/browse/SOLR-5345 Project: Solr Issue Type: Bug Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, 4.7 Typically the symptom with jenkins is strange socket failures (because sockets are files too). On my machine though i got the nice too many open files from lucene because it just happened to fail that way. In addition to holding thousands of open files, this test creates 90 *megabytes* of logging output! Can we tone down the test? I havent looked at all: but it doesn't seem necessary to have huge numbers of cores/indexes to test the functionality, we should be able to do this with relatively small numbers. Additionally i dont think its good to use random merge/IW buffering parameters here, we should set ones that won't make tons of files, force the use of compound file format, etc. The massive amounts of logging should be addressed too. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5657) When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode.
[ https://issues.apache.org/jira/browse/SOLR-5657?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-5657. --- Resolution: Fixed When a SolrCore starts on HDFS, it should gracefully handle HDFS being in safe mode. Key: SOLR-5657 URL: https://issues.apache.org/jira/browse/SOLR-5657 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-5657.patch Currently, things just fail. Ideally, the SolrCore would wait until safe mode was exited and resume loading. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5573) ChaosMonkey should randomly turn off Solr's commit on shutdown option.
[ https://issues.apache.org/jira/browse/SOLR-5573?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-5573. --- Resolution: Fixed ChaosMonkey should randomly turn off Solr's commit on shutdown option. -- Key: SOLR-5573 URL: https://issues.apache.org/jira/browse/SOLR-5573 Project: Solr Issue Type: Test Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 Because we don't have a great way kill (everything in the same JVM), this is very important for testing tlog replays on startup. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5345) OpenCloseCoreStressTest opens too many files (causing it to fail often)
[ https://issues.apache.org/jira/browse/SOLR-5345?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller updated SOLR-5345: -- Fix Version/s: 5.0 OpenCloseCoreStressTest opens too many files (causing it to fail often) --- Key: SOLR-5345 URL: https://issues.apache.org/jira/browse/SOLR-5345 Project: Solr Issue Type: Bug Reporter: Robert Muir Assignee: Mark Miller Fix For: 5.0, 4.7 Typically the symptom with jenkins is strange socket failures (because sockets are files too). On my machine though i got the nice too many open files from lucene because it just happened to fail that way. In addition to holding thousands of open files, this test creates 90 *megabytes* of logging output! Can we tone down the test? I havent looked at all: but it doesn't seem necessary to have huge numbers of cores/indexes to test the functionality, we should be able to do this with relatively small numbers. Additionally i dont think its good to use random merge/IW buffering parameters here, we should set ones that won't make tons of files, force the use of compound file format, etc. The massive amounts of logging should be addressed too. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5662) {!parent} parser with scoreMode
[
https://issues.apache.org/jira/browse/SOLR-5662?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Moritz Munte updated SOLR-5662:
---
Affects Version/s: 4.5
{!parent} parser with scoreMode
---
Key: SOLR-5662
URL: https://issues.apache.org/jira/browse/SOLR-5662
Project: Solr
Issue Type: Improvement
Affects Versions: 4.5, 4.6
Reporter: Moritz Munte
Priority: Minor
ToParentBlockJoinQuery has support for different score modes, but {!parent}
parser has None mode hardcoded without an option to change it.
It would be usefull if there is a parameter to change the score mode or set a
reasonable default.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5652) Heisenbug in DistribCursorPagingTest: walk already seen ...
[ https://issues.apache.org/jira/browse/SOLR-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881173#comment-13881173 ] Steve Rowe commented on SOLR-5652: -- I ran branch_4x DistribCursorPagingTest 1000 times in a bash loop overnight on Linux using Oracle Java 1.6.0_45 - no failures. Heisenbug in DistribCursorPagingTest: walk already seen ... - Key: SOLR-5652 URL: https://issues.apache.org/jira/browse/SOLR-5652 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Hoss Man Attachments: 129.log, 372.log, jenkins.thetaphi.de_Lucene-Solr-4.x-MacOSX_1200.log.txt, jenkins.thetaphi.de_Lucene-Solr-4.x-MacOSX_1217.log.txt Twice now, Uwe's jenkins has encountered a walk already seen ... assertion failure from DistribCursorPagingTest that I've been unable to fathom, let alone reproduce (although sarowe was able to trigger a similar, non-reproducible seed, failure on his machine) Using this as a tracking issue to try and make sense of it. Summary of things noticed so far (in 3 failures): * So far only seen on http://jenkins.thetaphi.de sarowe's mac * So far only seen on MacOSX * So far only seen on branch 4x * So far seen on both Java6 and Java7 * fails occured in first block of randomized testing: ** we've indexed a small number of randomized docs ** we're explicitly looping over every field and sorting in both directions * fails were both when doing a desc sorting on one of the \*_dv_last or \*_dv_first fields (docValues=true, either sortMissingLast=true OR sortMissingFirst=true) ** sort on same field asc has always worked fine just before this (fields are in arbitrary order, but asc always tried before desc) ** sorting on some other random fields has sometimes been tried before this and worked (specifics of each failure seen in the wild recorded in comments) -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5625) Add to testing for SolrCmdDistributor
[ https://issues.apache.org/jira/browse/SOLR-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881174#comment-13881174 ] ASF subversion and git services commented on SOLR-5625: --- Commit 1561079 from [~markrmil...@gmail.com] in branch 'dev/trunk' [ https://svn.apache.org/r1561079 ] SOLR-5625: Add testing around SolrCmdDistributor Add to testing for SolrCmdDistributor - Key: SOLR-5625 URL: https://issues.apache.org/jira/browse/SOLR-5625 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5625) Add to testing for SolrCmdDistributor
[ https://issues.apache.org/jira/browse/SOLR-5625?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881175#comment-13881175 ] ASF subversion and git services commented on SOLR-5625: --- Commit 1561080 from [~markrmil...@gmail.com] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1561080 ] SOLR-5625: Add testing around SolrCmdDistributor Add to testing for SolrCmdDistributor - Key: SOLR-5625 URL: https://issues.apache.org/jira/browse/SOLR-5625 Project: Solr Issue Type: Bug Components: SolrCloud Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Areek Zillur as Lucene/Solr committer!
Welcome Areek and good work! :) Otis -- Performance Monitoring * Log Analytics * Search Analytics Solr Elasticsearch Support * http://sematext.com/ On Tue, Jan 21, 2014 at 3:30 PM, Areek Zillur areek...@gmail.com wrote: Thanks Robert! I am very pleased to be a committer to Lucene/Solr! I am originally from Dhaka, Bangladesh. I am currently a 4th year Computer Engineering student at University of Waterloo in Canada. I was fortunate enough to have multiple internships all over North America through the university's co-op program. I was first introduced to Lucene/Solr in one of my work-terms at A9 and loved it. I really enjoy the open-source development and the friendliness of the community behind Lucene/Solr. In my free time, I enjoy working on working on my recreational algorithmic trading system and learning new programming languages. I hope to continue to work on Lucene/Solr and learn a lot more from the community! Thanks, Areek Zillur On Tue, Jan 21, 2014 at 11:41 AM, Yonik Seeley yo...@heliosearch.comwrote: Welcome Areek! -Yonik http://heliosearch.com -- making solr shine On Tue, Jan 21, 2014 at 2:26 PM, Robert Muir rcm...@gmail.com wrote: I'm pleased to announce that Areek Zillur has accepted to join our ranks as a committer. Areek has been improving suggester support in Lucene and Solr, including a revamped Solr component slated for the 4.7 release. [1] Areek, it is tradition that you introduce yourself with a brief bio. Once your account is setup, you should then be able to add yourself to the who we are page on the website as well. Congratulations and welcome! [1] https://issues.apache.org/jira/browse/SOLR-5378 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: Welcome Areek Zillur as Lucene/Solr committer!
Awesome; glad to have you Areek! ~ David Areek Zillur wrote Thanks Robert! I am very pleased to be a committer to Lucene/Solr! I am originally from Dhaka, Bangladesh. I am currently a 4th year Computer Engineering student at University of Waterloo in Canada. I was fortunate enough to have multiple internships all over North America through the university's co-op program. I was first introduced to Lucene/Solr in one of my work-terms at A9 and loved it. I really enjoy the open-source development and the friendliness of the community behind Lucene/Solr. In my free time, I enjoy working on working on my recreational algorithmic trading system and learning new programming languages. I hope to continue to work on Lucene/Solr and learn a lot more from the community! Thanks, Areek Zillur On Tue, Jan 21, 2014 at 11:41 AM, Yonik Seeley lt; yonik@ gt;wrote: Welcome Areek! -Yonik http://heliosearch.com -- making solr shine On Tue, Jan 21, 2014 at 2:26 PM, Robert Muir lt; rcmuir@ gt; wrote: I'm pleased to announce that Areek Zillur has accepted to join our ranks as a committer. Areek has been improving suggester support in Lucene and Solr, including a revamped Solr component slated for the 4.7 release. [1] Areek, it is tradition that you introduce yourself with a brief bio. Once your account is setup, you should then be able to add yourself to the who we are page on the website as well. Congratulations and welcome! [1] https://issues.apache.org/jira/browse/SOLR-5378 - To unsubscribe, e-mail: dev-unsubscribe@.apache For additional commands, e-mail: dev-help@.apache - Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/Welcome-Areek-Zillur-as-Lucene-Solr-committer-tp4112516p4113279.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5638) Collection creation partially works, but results in unusable configuration due to missing config in ZK
[ https://issues.apache.org/jira/browse/SOLR-5638?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881249#comment-13881249 ] Steve Molloy commented on SOLR-5638: Yes, we should fail fast instead of this, hence the comment about this not being the best solution. But it avoids seeing errors again and again about core not being able to load. As for recreating the collection in a different order, I haven't specifically checked, but assume you'd end up with the new cores properly created and the old ones would remain on disk, unloaded. Again, this isn't a real solution, just a band-aid to reduce the impact. Collection creation partially works, but results in unusable configuration due to missing config in ZK -- Key: SOLR-5638 URL: https://issues.apache.org/jira/browse/SOLR-5638 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.6 Reporter: Nathan Neulinger Attachments: SOLR-5638.patch Need help properly recovering from 'collection gets created without config being defined'. Right now, if you submit a collection create and the config is missing, it will proceed with partially creating cores, but then the cores fail to load. This requires manual intervention on the server to fix unless you pick a new colllection name: What's worse - if you retry the create a second time, it will usually try to create the replicas in the opposite order, resulting in TWO broken cores on each box, one for each attempted replica. beta1-newarch_hive1_v12_shard1_replica1: org.apache.solr.common.cloud.ZooKeeperException:org.apache.solr.common.cloud.ZooKeeperException: Specified config does not exist in ZooKeeper:hivepoint-unknown beta1-newarch_hive1_v12_shard1_replica2: org.apache.solr.common.cloud.ZooKeeperException:org.apache.solr.common.cloud.ZooKeeperException: Specified config does not exist in ZooKeeper:hivepoint-unknown I already know how to clear this up manually, but this is something where solr is allowing a condition in external service to result in a corrupted/partial configuration. I can see an easy option for resolving this as a workaround - allow a collection CREATE operation to specify reuseCores - i.e. allow it to use an existing core of the proper name if it already exists. Right now you wind up getting: org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error CREATEing SolrCore 'beta1-newarch_hive1_v12_shard1_replica1': Could not create a new core in solr/beta1-newarch_hive1_v12_shard1_replica1/as another core is already defined there org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Error CREATEing SolrCore 'beta1-newarch_hive1_v12_shard1_replica2': Could not create a new core in solr/beta1-newarch_hive1_v12_shard1_replica2/as another core is already defined there -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[ https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-5477: --- Attachment: SOLR-5477.patch Changed to using another implementation of storing data in zk. Not using DistributedQueue for anything but checking on the workQueue. The new implementation is a plain requestid based node map in zk and never really needs to do a getChildren or anything of that sort. Thanks for pointing that out Shalin. Async execution of OverseerCollectionProcessor tasks Key: SOLR-5477 URL: https://issues.apache.org/jira/browse/SOLR-5477 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Assignee: Anshum Gupta Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch Typical collection admin commands are long running and it is very common to have the requests get timed out. It is more of a problem if the cluster is very large.Add an option to run these commands asynchronously add an extra param async=true for all collection commands the task is written to ZK and the caller is returned a task id. as separate collection admin command will be added to poll the status of the task command=statusid=7657668909 if id is not passed all running async tasks should be listed A separate queue is created to store in-process tasks . After the tasks are completed the queue entry is removed. OverSeerColectionProcessor will perform these tasks in multiple threads -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[ https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-5477: --- Attachment: SOLR-5477.patch Seems like something got screwed up during 'svn diff'. Reposting the latest patch. Async execution of OverseerCollectionProcessor tasks Key: SOLR-5477 URL: https://issues.apache.org/jira/browse/SOLR-5477 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Assignee: Anshum Gupta Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch Typical collection admin commands are long running and it is very common to have the requests get timed out. It is more of a problem if the cluster is very large.Add an option to run these commands asynchronously add an extra param async=true for all collection commands the task is written to ZK and the caller is returned a task id. as separate collection admin command will be added to poll the status of the task command=statusid=7657668909 if id is not passed all running async tasks should be listed A separate queue is created to store in-process tasks . After the tasks are completed the queue entry is removed. OverSeerColectionProcessor will perform these tasks in multiple threads -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5643) ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue.
[ https://issues.apache.org/jira/browse/SOLR-5643?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Mark Miller resolved SOLR-5643. --- Resolution: Fixed ConcurrentUpdateSolrServer will sometimes not spawn a new Runner thread even though there are updates in the queue. --- Key: SOLR-5643 URL: https://issues.apache.org/jira/browse/SOLR-5643 Project: Solr Issue Type: Bug Reporter: Mark Miller Assignee: Mark Miller Fix For: 5.0, 4.7 Attachments: SOLR-5643.patch -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5589) Disabled replication in config is ignored
[ https://issues.apache.org/jira/browse/SOLR-5589?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Vitaliy Zhovtyuk updated SOLR-5589: --- Attachment: SOLR-5589.patch Added ReplicationHandler tests and configuration. ReplicationHandler state tested by details request (http://slave_host:port/solr/replication?command=details) and by getting handler statistic. Disabled replication in config is ignored - Key: SOLR-5589 URL: https://issues.apache.org/jira/browse/SOLR-5589 Project: Solr Issue Type: Bug Components: replication (java) Affects Versions: 4.5 Reporter: alexey Fix For: 4.7 Attachments: SOLR-5589.patch, SOLR-5589.patch When replication on master node is explicitly disabled in config, it is still enabled after start. This is because when both master and slave configurations are written with enabled=false, replication handler considers this node is a master and enables it. With proposed patch handler will consider this as master node but will disable replication on startup if it is disabled in config (equivalent to disablereplication command). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Closed] (SOLR-5407) Strange error condition with cloud replication not working quite right
[ https://issues.apache.org/jira/browse/SOLR-5407?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Nathan Neulinger closed SOLR-5407. -- Resolution: Unresolved Strange error condition with cloud replication not working quite right -- Key: SOLR-5407 URL: https://issues.apache.org/jira/browse/SOLR-5407 Project: Solr Issue Type: Bug Affects Versions: 4.5 Reporter: Nathan Neulinger Labels: cloud, replication I have a clodu deployment of 4.5 on EC2. Architecture is 3 dedicated ZK nodes, and a pair of solr nodes. I'll apologize in advance that this error report is not going to have a lot of detail, I'm really hoping that the scenario/description will trigger some likely possible explanation. The situation I got into was that the server had decided to fail over, so my app servers were all taking to what should have been the primary for most of the shards/collections, but actually was the replica. Here's where it gets odd - no errors being returned to the client code for any of the searches or document updates - and the current primary server was definitely receiving all of the updates - even though they were being submitted to the inactive/replica node. (clients talking to solr-p1, which was not primary at the time, and writes were being passed through to solr-r1, which was primary at the time.) All sounds good so far right? Except - the replica server at the time, through which the writes were passing - never got any of those content updates. It had an old unmodified copy of the index. I restarted solr-p1 (was the replica at the time) - no change in behavior. Behavior did not change until I killed and restarted the current primary (solr-r1) to force it to fail over. At that point, everything was all happy again and working properly. Until this morning, when one of the developers provisioned a new collection, which happened to put it's primary on solr-r1. Again, clients all pointing at solr-p1. The developer reported that the documents were going into the index, but not visible on the replica server. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5488) Fix up test failures for Analytics Component
[ https://issues.apache.org/jira/browse/SOLR-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steven Bower updated SOLR-5488: --- Attachment: SOLR-5488.patch Here is a new patch.. I have a theory about how this is happening but I can't repro so I can't validate.. but I re-org'd a bit of code and added some additional logging that will hopefully give more insight when this happens.. Fix up test failures for Analytics Component Key: SOLR-5488 URL: https://issues.apache.org/jira/browse/SOLR-5488 Project: Solr Issue Type: Bug Affects Versions: 5.0, 4.7 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch The analytics component has a few test failures, perhaps environment-dependent. This is just to collect the test fixes in one place for convenience when we merge back into 4.x -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5409) ToParentBlockJoinCollector.getTopGroups returns empty Groups
[ https://issues.apache.org/jira/browse/LUCENE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881342#comment-13881342 ] Peng Cheng commented on LUCENE-5409: That's a good point. but I also speculate that ToParentBJQ.rewrite() will change origChildQuery: Query rewritten = new ToParentBlockJoinQuery(childQuery, childRewrite, parentsFilter, scoreMode); if rewrite is executed twice, the origChildQuery won't be the same. ToParentBlockJoinCollector.getTopGroups returns empty Groups Key: LUCENE-5409 URL: https://issues.apache.org/jira/browse/LUCENE-5409 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.6 Environment: Ubuntu 12.04 Reporter: Peng Cheng Assignee: Michael McCandless Priority: Critical Fix For: 4.7 Original Estimate: 168h Remaining Estimate: 168h A bug is observed to cause unstable results returned by the getTopGroups function of class ToParentBlockJoinCollector. In the scorer generation stage, the ToParentBlockJoinCollector will automatically rewrite all the associated ToParentBlockJoinQuery (and their subqueries), and save them into its in-memory Look-up table, namely joinQueryID (see enroll() method for detail). Unfortunately, in the getTopGroups method, the new ToParentBlockJoinQuery parameter is not rewritten (at least users are not expected to do so). When the new one is searched in the old lookup table (considering the impact of rewrite() on hashCode()), the lookup will largely fail and eventually end up with a topGroup collection consisting of only empty groups (their hitCounts are guaranteed to be zero). An easy fix would be to rewrite the original BlockJoinQuery before invoking getTopGroups method. However, the computational cost of this is not optimal. A better but slightly more complex solution would be to save unrewrited Queries into the lookup table. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5395) Upgrade Spatial4j to 0.4
[ https://issues.apache.org/jira/browse/LUCENE-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881355#comment-13881355 ] ASF subversion and git services commented on LUCENE-5395: - Commit 1561129 from [~dsmiley] in branch 'dev/trunk' [ https://svn.apache.org/r1561129 ] LUCENE-5395: Upgrade Spatial4j 0.4. Moved away from stuff deprecated in Spatial4j. Upgrade Spatial4j to 0.4 Key: LUCENE-5395 URL: https://issues.apache.org/jira/browse/LUCENE-5395 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.7 Attachments: LUCENE-5395_Spatial4j_0_4.patch, LUCENE-5395_Spatial4j_0_4.patch Spatial4j 0.4 should be released the week of January 13th; a snapshot is published. A longer version of the delta from 0.4 is in [CHANGES.md|https://github.com/spatial4j/spatial4j/blob/master/CHANGES.md] A couple notable new features are: * Built-in WKT parser without relying on JTS. The older shape string format is deprecated. * A binary shape codec for reading writing the shapes to a byte-stream in a reasonably compact manner. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5409) ToParentBlockJoinCollector.getTopGroups returns empty Groups
[ https://issues.apache.org/jira/browse/LUCENE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881359#comment-13881359 ] Peng Cheng commented on LUCENE-5409: Wow I just changed rewritten code to use origChildQuery: Query rewritten = new ToParentBlockJoinQuery(origChildQuery, childRewrite, parentsFilter, scoreMode); and it passed all unit test, I never thought the fix being that easy. Thank you so much for pointing it out! Also, is it possible to close the trivial LUCENE-5398? ToParentBlockJoinCollector.getTopGroups returns empty Groups Key: LUCENE-5409 URL: https://issues.apache.org/jira/browse/LUCENE-5409 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.6 Environment: Ubuntu 12.04 Reporter: Peng Cheng Assignee: Michael McCandless Priority: Critical Fix For: 4.7 Original Estimate: 168h Remaining Estimate: 168h A bug is observed to cause unstable results returned by the getTopGroups function of class ToParentBlockJoinCollector. In the scorer generation stage, the ToParentBlockJoinCollector will automatically rewrite all the associated ToParentBlockJoinQuery (and their subqueries), and save them into its in-memory Look-up table, namely joinQueryID (see enroll() method for detail). Unfortunately, in the getTopGroups method, the new ToParentBlockJoinQuery parameter is not rewritten (at least users are not expected to do so). When the new one is searched in the old lookup table (considering the impact of rewrite() on hashCode()), the lookup will largely fail and eventually end up with a topGroup collection consisting of only empty groups (their hitCounts are guaranteed to be zero). An easy fix would be to rewrite the original BlockJoinQuery before invoking getTopGroups method. However, the computational cost of this is not optimal. A better but slightly more complex solution would be to save unrewrited Queries into the lookup table. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC4
+1 for http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ SUCCESS! [0:51:01.553003] Docs, changes and javadocs look good. Steve On Jan 23, 2014, at 9:57 PM, Mark Miller markrmil...@gmail.com wrote: Here we go, hopefully for that last time now…thanks everyone for bearing with us. Please vote to release the following artifacts: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ Here is my +1. SUCCESS! [0:56:37.409716] -- - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5395) Upgrade Spatial4j to 0.4
[ https://issues.apache.org/jira/browse/LUCENE-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881380#comment-13881380 ] ASF subversion and git services commented on LUCENE-5395: - Commit 1561142 from [~dsmiley] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1561142 ] LUCENE-5395: Upgrade Spatial4j 0.4. Moved away from stuff deprecated in Spatial4j. Upgrade Spatial4j to 0.4 Key: LUCENE-5395 URL: https://issues.apache.org/jira/browse/LUCENE-5395 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.7 Attachments: LUCENE-5395_Spatial4j_0_4.patch, LUCENE-5395_Spatial4j_0_4.patch Spatial4j 0.4 should be released the week of January 13th; a snapshot is published. A longer version of the delta from 0.4 is in [CHANGES.md|https://github.com/spatial4j/spatial4j/blob/master/CHANGES.md] A couple notable new features are: * Built-in WKT parser without relying on JTS. The older shape string format is deprecated. * A binary shape codec for reading writing the shapes to a byte-stream in a reasonably compact manner. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5402) SolrCloud 4.5 bulk add errors in cloud setup
[
https://issues.apache.org/jira/browse/SOLR-5402?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller resolved SOLR-5402.
---
Resolution: Fixed
Fix Version/s: 4.6
pretty sure this issue no longer exists. If it's spotted again we can reopen.
SolrCloud 4.5 bulk add errors in cloud setup
Key: SOLR-5402
URL: https://issues.apache.org/jira/browse/SOLR-5402
Project: Solr
Issue Type: Bug
Components: SolrCloud
Affects Versions: 4.5, 4.5.1
Reporter: Sai Gadde
Assignee: Mark Miller
Fix For: 5.0, 4.7, 4.6
We use out of the box Solr 4.5.1 no customization done. If we merge documents
via SolrJ to a single server it is perfectly working fine.
But as soon as we add another node to the cloud we are getting following
while merging documents. We merge about 500 at a time using SolrJ. These 500
documents in total are about few MB (1-3) in size.
This is the error we are getting on the server (10.10.10.116 - IP is
irrelavent just for clarity)where merging is happening. 10.10.10.119 is the
new node here. This server gets RemoteSolrException
shard update error StdNode:
http://10.10.10.119:8980/solr/mycore/:org.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:
Illegal to have multiple roots (start tag in epilog?).
at [row,col {unknown-source}]: [1,12468]
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:425)
at
org.apache.solr.client.solrj.impl.HttpSolrServer.request(HttpSolrServer.java:180)
at
org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:401)
at
org.apache.solr.update.SolrCmdDistributor$1.call(SolrCmdDistributor.java:1)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.Executors$RunnableAdapter.call(Unknown Source)
at java.util.concurrent.FutureTask$Sync.innerRun(Unknown Source)
at java.util.concurrent.FutureTask.run(Unknown Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Unknown
Source)
at java.util.concurrent.ThreadPoolExecutor$Worker.run(Unknown Source)
at java.lang.Thread.run(Unknown Source)
On the other server 10.10.10.119 we get following error
org.apache.solr.common.SolrException: Illegal to have multiple roots (start
tag in epilog?).
at [row,col {unknown-source}]: [1,12468]
at org.apache.solr.handler.loader.XMLLoader.load(XMLLoader.java:176)
at
org.apache.solr.handler.UpdateRequestHandler$1.load(UpdateRequestHandler.java:92)
at
org.apache.solr.handler.ContentStreamHandlerBase.handleRequestBody(ContentStreamHandlerBase.java:74)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859)
at
org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:703)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:406)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:195)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210)
at
org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:222)
at
org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:123)
at
org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:171)
at
org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:99)
at
org.apache.catalina.valves.AccessLogValve.invoke(AccessLogValve.java:936)
at
org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118)
at
org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407)
at
org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1004)
at
org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:589)
at
org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:310)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908)
at java.lang.Thread.run(Thread.java:662)
Caused by: com.ctc.wstx.exc.WstxParsingException: Illegal to have multiple
roots (start tag in epilog?).
at [row,col {unknown-source}]: [1,12369]
at
com.ctc.wstx.sr.StreamScanner.constructWfcException(StreamScanner.java:630)
[jira] [Resolved] (LUCENE-5395) Upgrade Spatial4j to 0.4
[ https://issues.apache.org/jira/browse/LUCENE-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved LUCENE-5395. -- Resolution: Fixed Upgrade Spatial4j to 0.4 Key: LUCENE-5395 URL: https://issues.apache.org/jira/browse/LUCENE-5395 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.7 Attachments: LUCENE-5395_Spatial4j_0_4.patch, LUCENE-5395_Spatial4j_0_4.patch Spatial4j 0.4 should be released the week of January 13th; a snapshot is published. A longer version of the delta from 0.4 is in [CHANGES.md|https://github.com/spatial4j/spatial4j/blob/master/CHANGES.md] A couple notable new features are: * Built-in WKT parser without relying on JTS. The older shape string format is deprecated. * A binary shape codec for reading writing the shapes to a byte-stream in a reasonably compact manner. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-4879) Indexing a field of type solr.SpatialRecursivePrefixTreeFieldType fails when at least two vertexes are more than 180 degrees apart
[ https://issues.apache.org/jira/browse/SOLR-4879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] David Smiley resolved SOLR-4879. Resolution: Fixed Fix Version/s: 4.7 Indexing a field of type solr.SpatialRecursivePrefixTreeFieldType fails when at least two vertexes are more than 180 degrees apart -- Key: SOLR-4879 URL: https://issues.apache.org/jira/browse/SOLR-4879 Project: Solr Issue Type: Bug Environment: Linux, Solr 4.0.0, Solr 4.3.0 Reporter: Øystein Torget Assignee: David Smiley Fix For: 4.7 When trying to index a field of the type solr.SpatialRecursivePrefixTreeFieldType the indexing will fail if two vertexes are more than 180 longitudal degress apart. For instance this polygon will fail: POLYGON((-161 49, 0 49, 20 49, 20 89.1, 0 89.1, -161 89.2,-161 49)) but this will not. POLYGON((-160 49, 0 49, 20 49, 20 89.1, 0 89.1, -160 89.2,-160 49)) This contradicts the documentation found here: http://wiki.apache.org/solr/SolrAdaptersForLuceneSpatial4 The documentation states that each vertex must be less than 180 longitudal degrees apart from the previous vertex. Relevant parts from the schema.xml file: !-- Field type for storing WTK based polygons -- fieldType name=location_rpt class=solr.SpatialRecursivePrefixTreeFieldType spatialContextFactory=com.spatial4j.core.context.jts.JtsSpatialContextFactory distErrPct=0.025 maxDistErr=0.09 units=degrees / field name=geographic_extent type=location_rpt index=true stored=true / -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-3814) Manhattan distance function is incorrect, not absolute distance between coordinates
[
https://issues.apache.org/jira/browse/LUCENE-3814?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
David Smiley resolved LUCENE-3814.
--
Resolution: Fixed
Fix Version/s: 4.7
Spatial4j 0.4 was released last week and just now Lucene/Solr trunk 4x was
updated to use it.
The fixed code is now deprecated in Spatial4j's DistanceUtils because the only
user of it is was Solr and it didn't really fit-in to the rest of Spatial4j.
So Solr's PointType now has this utility method.
Manhattan distance function is incorrect, not absolute distance between
coordinates
---
Key: LUCENE-3814
URL: https://issues.apache.org/jira/browse/LUCENE-3814
Project: Lucene - Core
Issue Type: Bug
Components: modules/spatial
Affects Versions: 4.0-ALPHA
Reporter: Neil Hooey
Assignee: David Smiley
Labels: distance, geometric
Fix For: 4.7
The Lucene vectorDistance() function's Manhattan distance function is
incorrect.
Wikipedia says: http://en.wikipedia.org/wiki/Manhattan_distance
Taxicab geometry, blahblahblah, is a form of geometry in which the usual
distance function or metric of Euclidean geometry is replaced by a new metric
in which the distance between two points is the sum of the *absolute
differences* of their coordinates.
The Lucene function isn't taking the absolute value before subtracting the
vector coordinates.
I don't have a patch, but the offending code is here:
{code}
//
lucene/contrib/spatial/src/java/org/apache/lucene/spatial/DistanceUtils.java
} else if (power == 1.0) {
for (int i = 0; i vec1.length; i++) {
result += vec1[i] - vec2[i];
}
{code}
It just needs to use Math.abs() when subtracting the coordinates.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[
https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881414#comment-13881414
]
Anshum Gupta edited comment on SOLR-5477 at 1/24/14 8:44 PM:
-
Added checking for existing tasks with the same id.
Have a lot of coming up in the logs. Trying to debug that.
{quote}
414075 [Overseer-91131269805768705-10.0.0.3:7574_solr-n_01] WARN
org.apache.solr.cloud.OverseerCollectionProcessor – Overseer cannot talk to ZK
414075 [Thread-16] ERROR org.apache.solr.cloud.Overseer – Exception in
Overseer main queue loop
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode =
ConnectionLoss for /overseer/queue...
{/quote}
was (Author: anshumg):
Added checking for existing tasks with the same id.
Have a lot of coming up in the logs. Trying to debug that.
{code}
414075 [Overseer-91131269805768705-10.0.0.3:7574_solr-n_01] WARN
org.apache.solr.cloud.OverseerCollectionProcessor – Overseer cannot talk to ZK
414075 [Thread-16] ERROR org.apache.solr.cloud.Overseer – Exception in
Overseer main queue loop
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode =
ConnectionLoss for /overseer/queue...
{/code}
Async execution of OverseerCollectionProcessor tasks
Key: SOLR-5477
URL: https://issues.apache.org/jira/browse/SOLR-5477
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Anshum Gupta
Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch
Typical collection admin commands are long running and it is very common to
have the requests get timed out. It is more of a problem if the cluster is
very large.Add an option to run these commands asynchronously
add an extra param async=true for all collection commands
the task is written to ZK and the caller is returned a task id.
as separate collection admin command will be added to poll the status of the
task
command=statusid=7657668909
if id is not passed all running async tasks should be listed
A separate queue is created to store in-process tasks . After the tasks are
completed the queue entry is removed. OverSeerColectionProcessor will perform
these tasks in multiple threads
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[
https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Anshum Gupta updated SOLR-5477:
---
Attachment: SOLR-5477.patch
Added checking for existing tasks with the same id.
Have a lot of coming up in the logs. Trying to debug that.
{code}
414075 [Overseer-91131269805768705-10.0.0.3:7574_solr-n_01] WARN
org.apache.solr.cloud.OverseerCollectionProcessor – Overseer cannot talk to ZK
414075 [Thread-16] ERROR org.apache.solr.cloud.Overseer – Exception in
Overseer main queue loop
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode =
ConnectionLoss for /overseer/queue...
{/code}
Async execution of OverseerCollectionProcessor tasks
Key: SOLR-5477
URL: https://issues.apache.org/jira/browse/SOLR-5477
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Anshum Gupta
Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch
Typical collection admin commands are long running and it is very common to
have the requests get timed out. It is more of a problem if the cluster is
very large.Add an option to run these commands asynchronously
add an extra param async=true for all collection commands
the task is written to ZK and the caller is returned a task id.
as separate collection admin command will be added to poll the status of the
task
command=statusid=7657668909
if id is not passed all running async tasks should be listed
A separate queue is created to store in-process tasks . After the tasks are
completed the queue entry is removed. OverSeerColectionProcessor will perform
these tasks in multiple threads
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[
https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881414#comment-13881414
]
Anshum Gupta edited comment on SOLR-5477 at 1/24/14 8:45 PM:
-
Added checking for existing tasks with the same id.
Have a lot of coming up in the logs. Trying to debug that.
{quote}
414075 [Overseer-91131269805768705-10.0.0.3:7574_solr-n_01] WARN
org.apache.solr.cloud.OverseerCollectionProcessor – Overseer cannot talk to ZK
414075 [Thread-16] ERROR org.apache.solr.cloud.Overseer – Exception in
Overseer main queue loop
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode =
ConnectionLoss for /overseer/queue...
at org.apache.zookeeper.KeeperException.create(KeeperException.java:99)
at org.apache.zookeeper.KeeperException.create(KeeperException.java:51)
at org.apache.zookeeper.ZooKeeper.getChildren(ZooKeeper.java:1468)
at
org.apache.solr.common.cloud.SolrZkClient$6.execute(SolrZkClient.java:256)
at
org.apache.solr.common.cloud.SolrZkClient$6.execute(SolrZkClient.java:253)
at
org.apache.solr.common.cloud.ZkCmdExecutor.retryOperation(ZkCmdExecutor.java:73)
{quote}
was (Author: anshumg):
Added checking for existing tasks with the same id.
Have a lot of coming up in the logs. Trying to debug that.
{quote}
414075 [Overseer-91131269805768705-10.0.0.3:7574_solr-n_01] WARN
org.apache.solr.cloud.OverseerCollectionProcessor – Overseer cannot talk to ZK
414075 [Thread-16] ERROR org.apache.solr.cloud.Overseer – Exception in
Overseer main queue loop
org.apache.zookeeper.KeeperException$ConnectionLossException: KeeperErrorCode =
ConnectionLoss for /overseer/queue...
{/quote}
Async execution of OverseerCollectionProcessor tasks
Key: SOLR-5477
URL: https://issues.apache.org/jira/browse/SOLR-5477
Project: Solr
Issue Type: Sub-task
Components: SolrCloud
Reporter: Noble Paul
Assignee: Anshum Gupta
Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch,
SOLR-5477.patch, SOLR-5477.patch
Typical collection admin commands are long running and it is very common to
have the requests get timed out. It is more of a problem if the cluster is
very large.Add an option to run these commands asynchronously
add an extra param async=true for all collection commands
the task is written to ZK and the caller is returned a task id.
as separate collection admin command will be added to poll the status of the
task
command=statusid=7657668909
if id is not passed all running async tasks should be listed
A separate queue is created to store in-process tasks . After the tasks are
completed the queue entry is removed. OverSeerColectionProcessor will perform
these tasks in multiple threads
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[ https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-5477: --- Attachment: SOLR-5477.patch Cleaned up patch. Working on: * Limiting the length of tracking data structures. * Returning more information for request status. * Tests. Async execution of OverseerCollectionProcessor tasks Key: SOLR-5477 URL: https://issues.apache.org/jira/browse/SOLR-5477 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Assignee: Anshum Gupta Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch Typical collection admin commands are long running and it is very common to have the requests get timed out. It is more of a problem if the cluster is very large.Add an option to run these commands asynchronously add an extra param async=true for all collection commands the task is written to ZK and the caller is returned a task id. as separate collection admin command will be added to poll the status of the task command=statusid=7657668909 if id is not passed all running async tasks should be listed A separate queue is created to store in-process tasks . After the tasks are completed the queue entry is removed. OverSeerColectionProcessor will perform these tasks in multiple threads -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5664) /browse: Show all highlighting fragments
Jan Høydahl created SOLR-5664: - Summary: /browse: Show all highlighting fragments Key: SOLR-5664 URL: https://issues.apache.org/jira/browse/SOLR-5664 Project: Solr Issue Type: Bug Components: contrib - Velocity Reporter: Jan Høydahl Fix For: 4.7 Currently if there are more highlighting fragments, only the first one is redered in the /browse GUI -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5652) Heisenbug in DistribCursorPagingTest: walk already seen ...
[
https://issues.apache.org/jira/browse/SOLR-5652?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881432#comment-13881432
]
Steve Rowe commented on SOLR-5652:
--
It looks to me like there are two problems here: 1) the same doc is showing up
on different pages when deep paging; and 2) missing docvalue docs are sorted
incorrectly.
I can easily find examples of problem #2 in logs of non-failing trials, e.g.
from trial #91 - when sort=long_dv_first+asc, missing value docs id=19, id=32
and id=37 are sorted as if they had the value 0, on the second page, when they
should be sorted first on the first page:
{noformat}
[junit4] 2 19554 T10 oasc.DistribCursorPagingTest.assertFullWalkNoDups
SOLR-5652:
({params(q=*%3A*fl=id%2Clong_dv_firstrows=31sort=long_dv_first+asc%2C+id+asc),defaults(cursorMark=*)})
gave us these docs: {id=49, long_dv_first=-8979994988935574161}; {id=92,
long_dv_first=-8755571709855874971}; {id=84,
long_dv_first=-8574119732015592678}; {id=56,
long_dv_first=-8572499504943249879}; {id=91,
long_dv_first=-8203042523619772390}; {id=75,
long_dv_first=-8115138008435097864}; {id=85,
long_dv_first=-7569390009163464752}; {id=58,
long_dv_first=-7543350239050885008}; {id=45,
long_dv_first=-7525477648502620266}; {id=80,
long_dv_first=-7520859819773031357}; {id=20,
long_dv_first=-7124229734364778199}; {id=64,
long_dv_first=-6830701259982220043}; {id=60,
long_dv_first=-6805829375857154103}; {id=2,
long_dv_first=-6659642971458854219}; {id=72,
long_dv_first=-6436183300694469323}; {id=41,
long_dv_first=-6013357013156317440}; {id=16,
long_dv_first=-5909224636078497253}; {id=90,
long_dv_first=-5891044973987397315}; {id=21,
long_dv_first=-5139637696689790888}; {id=95,
long_dv_first=-4964664340542583607}; {id=25,
long_dv_first=-4953002351284696779}; {id=101,
long_dv_first=-4409331376874778593}; {id=40,
long_dv_first=-4123215048596655849}; {id=4,
long_dv_first=-3899694572079828547}; {id=94,
long_dv_first=-3621827719107024030}; {id=29,
long_dv_first=-3602538116122488005}; {id=54,
long_dv_first=-3286165773326701533}; {id=5,
long_dv_first=-3144094377585650477}; {id=22,
long_dv_first=-3050916496497308906}; {id=71,
long_dv_first=-2534895618188255748}; {id=48,
long_dv_first=-2165485763197155213};
[junit4] 2 19567 T10 oasc.DistribCursorPagingTest.assertFullWalkNoDups
SOLR-5652:
({params(q=*%3A*fl=id%2Clong_dv_firstrows=31sort=long_dv_first+asc%2C+id+asc),defaults(cursorMark=AoIH4fKmK%2B53yHNQAw%3D%3D)})
gave us these docs: {id=76, long_dv_first=-1932456939352186404}; {id=68,
long_dv_first=-1878698959726559452}; {id=88,
long_dv_first=-1623167100548405744}; {id=83,
long_dv_first=-1589461579047178358}; {id=13,
long_dv_first=-1411021277082593064}; {id=74,
long_dv_first=-1013366478463336966}; {id=17,
long_dv_first=-946883306115055217}; {id=99, long_dv_first=-663522491219747257};
{id=42, long_dv_first=-92189538677577379}; {id=19}; {id=32}; {id=37}; {id=82,
long_dv_first=5004}; {id=97, long_dv_first=5006}; {id=24, long_dv_first=5012};
{id=11, long_dv_first=5013}; {id=87, long_dv_first=5035}; {id=33,
long_dv_first=5037}; {id=10, long_dv_first=5048}; {id=34, long_dv_first=5051};
{id=28, long_dv_first=5067}; {id=3, long_dv_first=5073}; {id=43,
long_dv_first=5076}; {id=23, long_dv_first=5083}; {id=89, long_dv_first=5087};
{id=8, long_dv_first=58919190259123570}; {id=51,
long_dv_first=225066202121560643}; {id=67, long_dv_first=844890816756093941};
{id=6, long_dv_first=1032728410845862227}; {id=36,
long_dv_first=1141671958716920319}; {id=96, long_dv_first=1226886190401658912};
{noformat}
TestDistributedMissingSort does not test sorting by docvalue - I'll work on
adding docvalue tests there.
Heisenbug in DistribCursorPagingTest: walk already seen ...
-
Key: SOLR-5652
URL: https://issues.apache.org/jira/browse/SOLR-5652
Project: Solr
Issue Type: Bug
Reporter: Hoss Man
Assignee: Hoss Man
Attachments: 129.log, 372.log,
jenkins.thetaphi.de_Lucene-Solr-4.x-MacOSX_1200.log.txt,
jenkins.thetaphi.de_Lucene-Solr-4.x-MacOSX_1217.log.txt
Twice now, Uwe's jenkins has encountered a walk already seen ... assertion
failure from DistribCursorPagingTest that I've been unable to fathom, let
alone reproduce (although sarowe was able to trigger a similar,
non-reproducible seed, failure on his machine)
Using this as a tracking issue to try and make sense of it.
Summary of things noticed so far (in 3 failures):
* So far only seen on http://jenkins.thetaphi.de sarowe's mac
* So far only seen on MacOSX
* So far only seen on branch 4x
* So far seen on both Java6 and Java7
* fails occured in first block of randomized testing:
** we've indexed a small number of randomized docs
** we're explicitly looping over every field and sorting in both
[jira] [Updated] (LUCENE-5410) Add fuzziness support to SimpleQueryParser
[
https://issues.apache.org/jira/browse/LUCENE-5410?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Lee Hinman updated LUCENE-5410:
---
Attachment: LUCENE-5410.patch
Here's a new version of the patch with these changes:
- Make only minimal changes to {{consumeToken}} and {{consumePhrase}}, all the
logic lives in separate parseFuzziness function used by both.
- Separate the flags for edit distance and slop, there is now
{{FUZZINESS_OPERATOR}} and {{SLOP_OPERATOR}}.
- More tests
Add fuzziness support to SimpleQueryParser
--
Key: LUCENE-5410
URL: https://issues.apache.org/jira/browse/LUCENE-5410
Project: Lucene - Core
Issue Type: Improvement
Components: core/queryparser
Affects Versions: 4.7
Reporter: Lee Hinman
Priority: Minor
Attachments: LUCENE-5410.patch, LUCENE-5410.patch, LUCENE-5410.patch
Original Estimate: 168h
Remaining Estimate: 168h
It would be nice to add fuzzy query support to the {{SimpleQueryParser}} so
that:
{{foo~2}}
generates a {{FuzzyQuery}} with an max edit distance of 2 and:
{{foo bar~2}}
generates a {{PhraseQuery}} with a slop of 2.
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
lucene-solr pull request: Fbs perf 1
GitHub user PaulElschot opened a pull request: https://github.com/apache/lucene-solr/pull/22 Fbs perf 1 This is a request to verify improved advance() performance of a FixedBitSet variant that uses Long.numberOfTrailingZeros() instead of the byte index currently used in OpenBitSetIterator. See the file lucene/core/remarks.txt for details. The file TestDocIdSetBenchmark.java in here currently has no APL 2, all the rest has it. You can merge this pull request into a Git repository by running: $ git pull https://github.com/PaulElschot/lucene-solr fbs_perf_1 Alternatively you can review and apply these changes as the patch at: https://github.com/apache/lucene-solr/pull/22.patch commit 0b4c85b1b30426f34f65a03c32bb2618e1d03f99 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-19T19:31:14Z Ignore *.*~ and *.jar files commit 9a3c80013219b986340cd5a470fb30d20d35504a Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-19T20:35:54Z Add first version of DocBlockIterator commit 77341eed771facde8cf89bc85c99fe0ccd6bd257 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-19T20:53:00Z OpenBitSetIterator extends DocBlockIterator, advanceToJustBefore() not yet implemented. commit d920b8e6f2fbf39da42a5eff19301c4ca92647c6 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-19T21:46:48Z Initial implementation of OpenBitSetIterator.advanceToJustBefore() commit ebff7763d31518989882909da56e0b9be22a4f89 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-19T21:57:38Z The OpenBitSetIterator constructor not using an OpenBitSet can not easily be deleted commit 4166b0e4fa44b10f7c25158a811ff8593d540957 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-19T22:16:30Z More detailed plan commit 807f98db323ee78454d6bb7d76a9d40d89e8126b Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-20T19:11:17Z Rename to DocBlocksIterator commit 7ea28b0443e62d4e02458943a06cd97a9c8ad843 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-20T19:17:09Z Rename to class DocBlocksIterator commit 42e4bbc18769f7f91a6dfd730cc5d7d51582cb6c Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-20T19:52:21Z Adapted ToParentBlockJoinQuery to use DocBlocksIterator directly from FBS, tests pass commit 3d7819bc9e3b8754e6f882e60a0920800ba09954 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-20T21:19:53Z Remove some commented code commit 4b2a7a4a529810dbf742958463c3f9327444f3b1 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-20T22:26:27Z Getting closer with ToChildBJQ commit 24032392ede9b8b2997152f4f6aec3af03a6e550 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-21T15:16:21Z Merge branch 'trunk' into docblocksiter commit 8fde265979ba8913045a3f9cd87a15482739cc43 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-21T16:49:48Z Always set OpenBitSet attribute in OpenBitSetIterator commit b7627dd4f41aff421af6d9a0781fcc13fe668995 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-21T16:51:06Z Added a test for advanceToJustBefore in BaseDocIdSetTestCase, TestFixedBitSet fails commit f1966ae5b4f375c7451ff083288e409a0b41b9ef Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-21T21:14:11Z Previous test seed passes, next one fails commit c198cd8b6b06187c65477f088dad918974721099 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-22T23:49:52Z Added OpenBitSetDocBlocksIterator commit c29094ceba3bec8773e51c17fe3c80abab5ae526 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-22T23:53:00Z Merge branch 'trunk' of https://github.com/apache/lucene-solr into docblocksiter commit 7f7d8901bb396b82a0e874ca1f3c4264806fcd8e Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-23T20:37:49Z Improve ignoring lib directories commit e8abc6f30060ac10de886b6fcc225d561e4758b5 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-23T21:20:13Z Added FixedBitSetDBI, tests pass. FixedBitSet.java from trunk, made some private things protected. commit f78dca9bdf2b79fe3fbb7b80898fb88420891418 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-23T21:30:05Z Remove some unused imports commit 273a7e80767252f9748878878b0e9d742d2df669 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-23T21:33:17Z Remove commented println lines commit 3f93aa8d76422844d141fc2070a236e780e577f8 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-23T23:24:09Z Add TestDocIdSetBenchMark.java. Note: no APL 2.0 commit 3ca778ffee79cc9bd549e4b0dd37e00f16ba6320 Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-23T23:26:06Z Add assert message commit 50f0175fda3637b88e982f285021921c69fe4dff Author: Paul Elschot paul.j.elsc...@gmail.com Date: 2014-01-23T23:26:22Z Correct comment commit
[jira] [Commented] (LUCENE-5409) ToParentBlockJoinCollector.getTopGroups returns empty Groups
[ https://issues.apache.org/jira/browse/LUCENE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881464#comment-13881464 ] Michael McCandless commented on LUCENE-5409: Ahh ... two rewrites will store the wrong origChildQuery. Nice catch :) But: do we first have a failing test case here? Also, were you rewriting yourself externally in your application? Or is there some path through Lucene that results in more than one rewrite? ToParentBlockJoinCollector.getTopGroups returns empty Groups Key: LUCENE-5409 URL: https://issues.apache.org/jira/browse/LUCENE-5409 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.6 Environment: Ubuntu 12.04 Reporter: Peng Cheng Assignee: Michael McCandless Priority: Critical Fix For: 4.7 Original Estimate: 168h Remaining Estimate: 168h A bug is observed to cause unstable results returned by the getTopGroups function of class ToParentBlockJoinCollector. In the scorer generation stage, the ToParentBlockJoinCollector will automatically rewrite all the associated ToParentBlockJoinQuery (and their subqueries), and save them into its in-memory Look-up table, namely joinQueryID (see enroll() method for detail). Unfortunately, in the getTopGroups method, the new ToParentBlockJoinQuery parameter is not rewritten (at least users are not expected to do so). When the new one is searched in the old lookup table (considering the impact of rewrite() on hashCode()), the lookup will largely fail and eventually end up with a topGroup collection consisting of only empty groups (their hitCounts are guaranteed to be zero). An easy fix would be to rewrite the original BlockJoinQuery before invoking getTopGroups method. However, the computational cost of this is not optimal. A better but slightly more complex solution would be to save unrewrited Queries into the lookup table. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5414) suggest module should not depend on expression module
[ https://issues.apache.org/jira/browse/LUCENE-5414?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Simon Willnauer updated LUCENE-5414: Attachment: LUCENE-5414.patch updated patch: * Renamed DocumentExpressionDictionary to DocumentValueSourceDictionary * Fixed JavaDocs * Fixed DocumentExpressionDictionaryFactory to still accept an expression. I also kept the name since it adds this functionality on top of the DocumentValueSourceDictionary. I am not set on the name we could also go for WeightedDocumentDictionary? suggest module should not depend on expression module - Key: LUCENE-5414 URL: https://issues.apache.org/jira/browse/LUCENE-5414 Project: Lucene - Core Issue Type: Wish Affects Versions: 4.6, 5.0 Reporter: Simon Willnauer Fix For: 5.0, 4.7 Attachments: LUCENE-5414.patch, LUCENE-5414.patch, LUCENE-5414.patch Currently our suggest module depends on the expression module just because the DocumentExpressionDictionary provides some util ctor to pass in an expression directly. That is a lot of dependency for little value IMO and pulls in lots of JARs. DocumentExpressionDictionary should only take a ValueSource instead. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5416) Performance of a FixedBitSet variant that uses Long.numberOfTrailingZeros()
Paul Elschot created LUCENE-5416: Summary: Performance of a FixedBitSet variant that uses Long.numberOfTrailingZeros() Key: LUCENE-5416 URL: https://issues.apache.org/jira/browse/LUCENE-5416 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 5.0 Reporter: Paul Elschot Priority: Minor Fix For: 5.0 On my machine the current byte index used in OpenBitSetIterator is slower than Long.numberOfTrailingZeros() for advance(). The pull request contains the code for benchmarking this taken from an early stage of DocBlocksIterator. In case the benchmark shows improvements on more machines, well, we know what to do... -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5416) Performance of a FixedBitSet variant that uses Long.numberOfTrailingZeros()
[ https://issues.apache.org/jira/browse/LUCENE-5416?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881480#comment-13881480 ] Paul Elschot commented on LUCENE-5416: -- See this pull request for the code: https://github.com/apache/lucene-solr/pull/22 There is also a remarks.txt there. I did not clean the commits in the github repo, please look at the changes. At the pull request I did not see the possibilty to download a patch, in case one is preferred, please let me know. Performance of a FixedBitSet variant that uses Long.numberOfTrailingZeros() --- Key: LUCENE-5416 URL: https://issues.apache.org/jira/browse/LUCENE-5416 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 5.0 Reporter: Paul Elschot Priority: Minor Fix For: 5.0 On my machine the current byte index used in OpenBitSetIterator is slower than Long.numberOfTrailingZeros() for advance(). The pull request contains the code for benchmarking this taken from an early stage of DocBlocksIterator. In case the benchmark shows improvements on more machines, well, we know what to do... -- This message was sent by Atlassian JIRA (v6.1.5#6160) - 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_51) - Build # 9224 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9224/ Java: 32bit/jdk1.7.0_51 -server -XX:+UseParallelGC All tests passed Build Log: [...truncated 20290 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:453: The following error occurred while executing this line: /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:162: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/custom-tasks.xml:62: License check failed. Check the logs. Total time: 53 minutes 38 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 32bit/jdk1.7.0_51 -server -XX:+UseParallelGC Archiving artifacts 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
[jira] [Commented] (LUCENE-5415) Support wildcard co in PostingsHighlighter
[ https://issues.apache.org/jira/browse/LUCENE-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881494#comment-13881494 ] Michael McCandless commented on LUCENE-5415: I love this approach! Assuming the analyzer is not too costly, this ought to scale much better than rewrite Query up front workaround when the query matches tons of terms, i.e. it's less susceptible to an adversary. The patch is surprisingly simple :) How will the FakeDocsEnum.freq() lie affect the default PassageScorer? Will this bias against passages that had an MTQ match? So, all MTQs are squished into a single fake/virtual term for matching, like I cannot tell which of the N MTQs in my query caused the hit. I think this is OK for starters: it's unusual (maybe?) to run multiple MTQs and to *also* care about which one matched each hit in the highlight. But I guess we could instead add N virtual terms, one per MTQ... later. Support wildcard co in PostingsHighlighter Key: LUCENE-5415 URL: https://issues.apache.org/jira/browse/LUCENE-5415 Project: Lucene - Core Issue Type: Improvement Components: modules/highlighter Reporter: Robert Muir Attachments: LUCENE-5415.patch PostingsHighlighter uses the offsets encoded in the postings lists for the terms to find query matches. As such, it isn't really suitable for stuff like wildcards for two reasons: 1. an expensive rewrite against the term dictionary (i think other highlighters share this problem) 2. accumulating data from potentially many terms (e.g. reading many postings) However, we could provide an option for some of these queries to work, but in a different way, that avoids these downsides. Instead we can just grab the Automaton representation of the queries, and match it against the content directly (which won't blow up). -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5409) ToParentBlockJoinCollector.getTopGroups returns empty Groups
[ https://issues.apache.org/jira/browse/LUCENE-5409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881505#comment-13881505 ] Peng Cheng commented on LUCENE-5409: Not yet, I'm trying to find a special case. I never rewrite myself (so does most of lucene users) but IndexSearcher.rewrite method used in search(...) will rewrite any query recursively until it reaches the final stage. ToParentBlockJoinCollector.getTopGroups returns empty Groups Key: LUCENE-5409 URL: https://issues.apache.org/jira/browse/LUCENE-5409 Project: Lucene - Core Issue Type: Bug Components: core/search Affects Versions: 4.6 Environment: Ubuntu 12.04 Reporter: Peng Cheng Assignee: Michael McCandless Priority: Critical Fix For: 4.7 Original Estimate: 168h Remaining Estimate: 168h A bug is observed to cause unstable results returned by the getTopGroups function of class ToParentBlockJoinCollector. In the scorer generation stage, the ToParentBlockJoinCollector will automatically rewrite all the associated ToParentBlockJoinQuery (and their subqueries), and save them into its in-memory Look-up table, namely joinQueryID (see enroll() method for detail). Unfortunately, in the getTopGroups method, the new ToParentBlockJoinQuery parameter is not rewritten (at least users are not expected to do so). When the new one is searched in the old lookup table (considering the impact of rewrite() on hashCode()), the lookup will largely fail and eventually end up with a topGroup collection consisting of only empty groups (their hitCounts are guaranteed to be zero). An easy fix would be to rewrite the original BlockJoinQuery before invoking getTopGroups method. However, the computational cost of this is not optimal. A better but slightly more complex solution would be to save unrewrited Queries into the lookup table. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5353) ShingleFilter should have a way to specify FILLER_TOKEN
[ https://issues.apache.org/jira/browse/LUCENE-5353?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ahmet Arslan updated LUCENE-5353: - Attachment: LUCENE-5353.patch ShingleFilter should have a way to specify FILLER_TOKEN --- Key: LUCENE-5353 URL: https://issues.apache.org/jira/browse/LUCENE-5353 Project: Lucene - Core Issue Type: Improvement Components: modules/analysis Affects Versions: 4.6 Reporter: Simon Willnauer Fix For: 5.0, 4.7 Attachments: LUCENE-5353.patch Today we have no choice that if pos_inc is 1 there will be a `_` inserted in between the tokens. We should have the ability to change this character and the char[] that holds it should not be public static since it's mutable. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - 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 (64bit/jdk1.7.0_60-ea-b03) - Build # 9122 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9122/ Java: 64bit/jdk1.7.0_60-ea-b03 -XX:+UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 20296 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:459: The following error occurred while executing this line: /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:162: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/custom-tasks.xml:62: License check failed. Check the logs. Total time: 47 minutes 26 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 64bit/jdk1.7.0_60-ea-b03 -XX:+UseCompressedOops -XX:+UseParallelGC Archiving artifacts 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] Lucene-Solr-4.x-Linux (64bit/jdk1.7.0_60-ea-b03) - Build # 9122 - Still Failing!
check-licenses: [echo] License check under: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene [licenses] CHECKSUM FAILED for /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/benchmark/lib/spatial4j-0.4.jar (expected: 28b666145773098aeeadd033f3dd6c5b2871c208 was: 3fb96c751e83cd815b68e5f53d058f2cb8a9ecaa) [licenses] CHECKSUM FAILED for /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/spatial/lib/spatial4j-0.4.jar (expected: 28b666145773098aeeadd033f3dd6c5b2871c208 was: 3fb96c751e83cd815b68e5f53d058f2cb8a9ecaa) [licenses] Scanned 34 JAR file(s) for licenses (in 0.53s.), 2 error(s). On Jan 24, 2014, at 6:13 PM, Policeman Jenkins Server jenk...@thetaphi.de wrote: Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/9122/ Java: 64bit/jdk1.7.0_60-ea-b03 -XX:+UseCompressedOops -XX:+UseParallelGC All tests passed Build Log: [...truncated 20296 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/build.xml:459: The following error occurred while executing this line: /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:162: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-4.x-Linux/lucene/tools/custom-tasks.xml:62: License check failed. Check the logs. Total time: 47 minutes 26 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 64bit/jdk1.7.0_60-ea-b03 -XX:+UseCompressedOops -XX:+UseParallelGC Archiving artifacts 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 - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5488) Fix up test failures for Analytics Component
[ https://issues.apache.org/jira/browse/SOLR-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881549#comment-13881549 ] Erick Erickson commented on SOLR-5488: -- Still the same problem, or a close variant: ant test -Dtestcase=FunctionTest -Dtests.seed=32D06837FE8C4122 -Dtests.slow=true -Dtests.locale=et -Dtests.timezone=Etc/GMT+3 -Dtests.file.encoding=US-ASCII 2 570438 T4357 C1115 oasc.SolrException.log ERROR java.lang.IllegalArgumentException: No stat named 'median' in this collector [junit4] 2at org.apache.solr.analytics.statistics.MinMaxStatsCollector.getStat(MinMaxStatsCollector.java:86) [junit4] 2at org.apache.solr.analytics.expression.BaseExpression.getValue(BaseExpression.java:38) [junit4] 2at org.apache.solr.analytics.accumulator.BasicAccumulator.export(BasicAccumulator.java:116) [junit4] 2at org.apache.solr.analytics.request.AnalyticsStats.execute(AnalyticsStats.java:132) [junit4] 2at org.apache.solr.handler.component.AnalyticsComponent.process(AnalyticsComponent.java:44) [junit4] 2at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:215) [junit4] 2at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) [junit4] 2at org.apache.solr.core.SolrCore.execute(SolrCore.java:1915) [junit4] 2at org.apache.solr.util.TestHarness.query(TestHarness.java:291) [junit4] 2at org.apache.solr.util.TestHarness.query(TestHarness.java:273) [junit4] 2at org.apache.solr.analytics.util.valuesource.FunctionTest.beforeClass(FunctionTest.java:85) [junit4] 2at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) [junit4] 2at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) [junit4] 2at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) [junit4] 2at java.lang.reflect.Method.invoke(Method.java:601) [junit4] 2at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) [junit4] 2at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) [junit4] 2at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:677) [junit4] 2at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) [junit4] 2at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4] 2at com.carrotsearch.randomizedtesting.rules.SystemPropertiesRestoreRule$1.evaluate(SystemPropertiesRestoreRule.java:53) [junit4] 2at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) [junit4] 2at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) [junit4] 2at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) [junit4] 2at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) [junit4] 2at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) [junit4] 2at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4] 2at org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) [junit4] 2at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) [junit4] 2at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) [junit4] 2at org.apache.lucene.util.TestRuleIgnoreTestSuites$1.evaluate(TestRuleIgnoreTestSuites.java:55) [junit4] 2at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) [junit4] 2at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) [junit4] 2at java.lang.Thread.run(Thread.java:722) [junit4] 2 [junit4] 2 ASYNC NEW_CORE C1116 name=collection1 org.apache.solr.core.SolrCore@412cebbe [junit4] 2 570450 T4357 C1116 oasc.SolrCore.execute [collection1] webapp=null path=null
[jira] [Commented] (LUCENE-5415) Support wildcard co in PostingsHighlighter
[
https://issues.apache.org/jira/browse/LUCENE-5415?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881548#comment-13881548
]
Robert Muir commented on LUCENE-5415:
-
{quote}
How will the FakeDocsEnum.freq() lie affect the default PassageScorer? Will
this bias against passages that had an MTQ match?
{quote}
Terribly. Yes. Its a prototype :) But remember: these are typically
constant-score in lucene.
{quote}
So, all MTQs are squished into a single fake/virtual term for matching, like I
cannot tell which of the N MTQs in my query caused the hit. I think this is OK
for starters: it's unusual (maybe?) to run multiple MTQs and to also care about
which one matched each hit in the highlight. But I guess we could instead add N
virtual terms, one per MTQ... later.
{quote}
Same as above: its a prototype. I avoided an automaton UNION operation (scared
of perf, and well, multiple MTQs are rarish). But who uses the API to look at
the terms? Does telling them which MTQ matched really seem that important?
(nothing in the highlighter api uses this today!!) They have the offsets to
know the actual text that matched still, so i mean... I think its ok for now?
In both cases: I tried to avoid special casing this stuff (sorry, i think if
you have a serious search system, then wildcards are rare), and instead add
them in a non-disruptive way so that its clear it doesnt break the algorithm,
which I think is generally working ok.
Support wildcard co in PostingsHighlighter
Key: LUCENE-5415
URL: https://issues.apache.org/jira/browse/LUCENE-5415
Project: Lucene - Core
Issue Type: Improvement
Components: modules/highlighter
Reporter: Robert Muir
Attachments: LUCENE-5415.patch
PostingsHighlighter uses the offsets encoded in the postings lists for the
terms to find query matches.
As such, it isn't really suitable for stuff like wildcards for two reasons:
1. an expensive rewrite against the term dictionary (i think other
highlighters share this problem)
2. accumulating data from potentially many terms (e.g. reading many postings)
However, we could provide an option for some of these queries to work, but in
a different way, that avoids these downsides.
Instead we can just grab the Automaton representation of the queries, and
match it against the content directly (which won't blow up).
--
This message was sent by Atlassian JIRA
(v6.1.5#6160)
-
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.8.0-ea-b124) - Build # 9225 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9225/ Java: 32bit/jdk1.8.0-ea-b124 -client -XX:+UseG1GC All tests passed Build Log: [...truncated 20310 lines...] BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:453: The following error occurred while executing this line: /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:162: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/custom-tasks.xml:62: License check failed. Check the logs. Total time: 50 minutes 55 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 32bit/jdk1.8.0-ea-b124 -client -XX:+UseG1GC Archiving artifacts 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] Lucene-Solr-trunk-Linux (32bit/jdk1.7.0_51) - Build # 9224 - Failure!
Whoops; I thought I got the sha1's correctly; I'll try again. - Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/JENKINS-Lucene-Solr-trunk-Linux-32bit-jdk1-7-0-51-Build-9224-Failure-tp4113340p4113363.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [VOTE] Release Lucene/Solr 4.6.1 RC4
On Thu, 23 Jan 2014, Mark Miller wrote: Sorry - watch out for that link - I?m seeing the text correctly, but the underlying link incorrectly when I look at it in my send folder. The evils of html mail I guess. +1 PyLucene built from branch_4x's rev 1560866 passes all its tests. Andi.. To be sure you have the right artifacts, make sure you are looking at the following location: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ - Mark On Jan 23, 2014, at 9:57 PM, Mark Miller markrmil...@gmail.com wrote: Here we go, hopefully for that last time now?thanks everyone for bearing with us. Please vote to release the following artifacts: http://people.apache.org/~markrmiller/lucene_solr_4_6_1r1560866/ Here is my +1. SUCCESS! [0:56:37.409716] -- - Mark - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5395) Upgrade Spatial4j to 0.4
[ https://issues.apache.org/jira/browse/LUCENE-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881557#comment-13881557 ] ASF subversion and git services commented on LUCENE-5395: - Commit 1561238 from [~dsmiley] in branch 'dev/trunk' [ https://svn.apache.org/r1561238 ] LUCENE-5395: calculated sha1 via ant jar-checksums this time Upgrade Spatial4j to 0.4 Key: LUCENE-5395 URL: https://issues.apache.org/jira/browse/LUCENE-5395 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.7 Attachments: LUCENE-5395_Spatial4j_0_4.patch, LUCENE-5395_Spatial4j_0_4.patch Spatial4j 0.4 should be released the week of January 13th; a snapshot is published. A longer version of the delta from 0.4 is in [CHANGES.md|https://github.com/spatial4j/spatial4j/blob/master/CHANGES.md] A couple notable new features are: * Built-in WKT parser without relying on JTS. The older shape string format is deprecated. * A binary shape codec for reading writing the shapes to a byte-stream in a reasonably compact manner. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5395) Upgrade Spatial4j to 0.4
[ https://issues.apache.org/jira/browse/LUCENE-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881558#comment-13881558 ] ASF subversion and git services commented on LUCENE-5395: - Commit 1561239 from [~dsmiley] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1561239 ] LUCENE-5395: calculated sha1 via ant jar-checksums this time Upgrade Spatial4j to 0.4 Key: LUCENE-5395 URL: https://issues.apache.org/jira/browse/LUCENE-5395 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.7 Attachments: LUCENE-5395_Spatial4j_0_4.patch, LUCENE-5395_Spatial4j_0_4.patch Spatial4j 0.4 should be released the week of January 13th; a snapshot is published. A longer version of the delta from 0.4 is in [CHANGES.md|https://github.com/spatial4j/spatial4j/blob/master/CHANGES.md] A couple notable new features are: * Built-in WKT parser without relying on JTS. The older shape string format is deprecated. * A binary shape codec for reading writing the shapes to a byte-stream in a reasonably compact manner. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-2366) Facet Range Gaps
[ https://issues.apache.org/jira/browse/SOLR-2366?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ted Sullivan updated SOLR-2366: --- Attachment: SOLR-2366.patch Updated the patch to the current svn trunk. The old patch does not work anymore because the paths have changed since this was uploaded. Facet Range Gaps Key: SOLR-2366 URL: https://issues.apache.org/jira/browse/SOLR-2366 Project: Solr Issue Type: Improvement Reporter: Grant Ingersoll Assignee: Shalin Shekhar Mangar Priority: Minor Fix For: 4.7 Attachments: SOLR-2366.patch, SOLR-2366.patch, SOLR-2366.patch There really is no reason why the range gap for date and numeric faceting needs to be evenly spaced. For instance, if and when SOLR-1581 is completed and one were doing spatial distance calculations, one could facet by function into 3 different sized buckets: walking distance (0-5KM), driving distance (5KM-150KM) and everything else (150KM+), for instance. We should be able to quantize the results into arbitrarily sized buckets. (Original syntax proposal removed, see discussion for concrete syntax) -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5417) Solr function query supports reading multiple values from a field.
Peng Cheng created LUCENE-5417: -- Summary: Solr function query supports reading multiple values from a field. Key: LUCENE-5417 URL: https://issues.apache.org/jira/browse/LUCENE-5417 Project: Lucene - Core Issue Type: New Feature Components: core/query/scoring Affects Versions: 4.6 Environment: N/A Reporter: Peng Cheng Priority: Minor Fix For: 4.7 Solr function query is a powerful tool to customize search criterion and ranking function (http://wiki.apache.org/solr/FunctionQuery). However, it cannot effectively benefit from field values from multi-valued field, namely, the field(...) function can only read one value and discard the others. This limitation has been associated with FieldCacheSource, and the fact that FieldCache cannot fetch multiple values from a field, but such constraint has been largely lifted by LUCENE-3354, which allows multiple values to be extracted from one field. Those values in turn can be used as parameters of other functions to yield a single score. I personally find this limitation very unhandy when building a learning-to-rank system that uses many cues and string features. Therefore I would like to post this feature request and (hopefully) work on it myself. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5417) Solr function query supports reading multiple values from a field.
[ https://issues.apache.org/jira/browse/LUCENE-5417?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881570#comment-13881570 ] Peng Cheng commented on LUCENE-5417: I didn't check the issue history and am not sure if this problem has been solved, please revoke this one if its a duplicate. Solr function query supports reading multiple values from a field. -- Key: LUCENE-5417 URL: https://issues.apache.org/jira/browse/LUCENE-5417 Project: Lucene - Core Issue Type: New Feature Components: core/query/scoring Affects Versions: 4.6 Environment: N/A Reporter: Peng Cheng Priority: Minor Fix For: 4.7 Original Estimate: 168h Remaining Estimate: 168h Solr function query is a powerful tool to customize search criterion and ranking function (http://wiki.apache.org/solr/FunctionQuery). However, it cannot effectively benefit from field values from multi-valued field, namely, the field(...) function can only read one value and discard the others. This limitation has been associated with FieldCacheSource, and the fact that FieldCache cannot fetch multiple values from a field, but such constraint has been largely lifted by LUCENE-3354, which allows multiple values to be extracted from one field. Those values in turn can be used as parameters of other functions to yield a single score. I personally find this limitation very unhandy when building a learning-to-rank system that uses many cues and string features. Therefore I would like to post this feature request and (hopefully) work on it myself. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5488) Fix up test failures for Analytics Component
[ https://issues.apache.org/jira/browse/SOLR-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881574#comment-13881574 ] Steven Bower commented on SOLR-5488: Could provide the logs from above the exception.. this is where the new logging info should be.. thanks! I'm going to try to repro on another computer to see if I can possibly get it to repro as this is a painful process (which I appreciate your patience with) Fix up test failures for Analytics Component Key: SOLR-5488 URL: https://issues.apache.org/jira/browse/SOLR-5488 Project: Solr Issue Type: Bug Affects Versions: 5.0, 4.7 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch The analytics component has a few test failures, perhaps environment-dependent. This is just to collect the test fixes in one place for convenience when we merge back into 4.x -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5488) Fix up test failures for Analytics Component
[ https://issues.apache.org/jira/browse/SOLR-5488?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-5488: - Attachment: eoe.errors Here it is. Fix up test failures for Analytics Component Key: SOLR-5488 URL: https://issues.apache.org/jira/browse/SOLR-5488 Project: Solr Issue Type: Bug Affects Versions: 5.0, 4.7 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, SOLR-5488.patch, eoe.errors The analytics component has a few test failures, perhaps environment-dependent. This is just to collect the test fixes in one place for convenience when we merge back into 4.x -- This message was sent by Atlassian JIRA (v6.1.5#6160) - 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.8.0-ea-b124) - Build # 9226 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9226/ Java: 32bit/jdk1.8.0-ea-b124 -client -XX:+UseG1GC All tests passed Build Log: [...truncated 30701 lines...] -check-forbidden-base: [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.7 [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.7 [forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.1 [forbidden-apis] Reading API signatures: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/base.txt [forbidden-apis] Reading API signatures: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/servlet-api.txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning for API signatures and dependencies... [forbidden-apis] Forbidden method invocation: java.lang.String#toUpperCase() [Uses default locale] [forbidden-apis] in org.apache.solr.schema.AbstractSpatialFieldType (AbstractSpatialFieldType.java:95) [forbidden-apis] Scanned 2047 (and 1345 related) class file(s) for forbidden API invocations (in 1.41s), 1 error(s). BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:453: The following error occurred while executing this line: /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/solr/build.xml:271: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:474: Check for forbidden API calls failed, see log. Total time: 50 minutes 21 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 32bit/jdk1.8.0-ea-b124 -client -XX:+UseG1GC Archiving artifacts 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
[jira] [Commented] (SOLR-5661) PriorityQueue has OOM (Requested array size exceeds VM limit) issue
[ https://issues.apache.org/jira/browse/SOLR-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881610#comment-13881610 ] Raintung Li commented on SOLR-5661: --- If you have multiple shard for one collection, send the query url for max integer rowid, it can easy replicate. Caused by: java.lang.OutOfMemoryError: Requested array size exceeds VM limit at org.apache.lucene.util.PriorityQueue.init(PriorityQueue.java:64) at org.apache.lucene.util.PriorityQueue.init(PriorityQueue.java:37) at org.apache.solr.handler.component.ShardFieldSortedHitQueue.init(ShardDoc.java:113) at org.apache.solr.handler.component.QueryComponent.mergeIds(QueryComponent.java:790) at org.apache.solr.handler.component.QueryComponent.handleRegularResponses(QueryComponent.java:649) at org.apache.solr.handler.component.QueryComponent.handleResponses(QueryComponent.java:628) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:311) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1859) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:710) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:413) PriorityQueue has OOM (Requested array size exceeds VM limit) issue --- Key: SOLR-5661 URL: https://issues.apache.org/jira/browse/SOLR-5661 Project: Solr Issue Type: Bug Components: contrib - Solr Cell (Tika extraction) Affects Versions: 4.3.1, 4.4, 4.5, 4.5.1, 4.6 Environment: JDK 7 Reporter: Raintung Li It look like JDK7 change the design for max_array_length logic, it isn't max_jint, and it should be max_jint - header_size(type). If you deliver the Integer.MaxValue to create the PriorityQueue and have enough memory, you will find it is ok in JVM6 but not work in JVM7. JVM7 will throw OOM error while do array rang checking. It should the compatible issue between JVM6 and JVM7. Maybe need protect in the code logic, throw OOM look like big issues for customer. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5661) PriorityQueue has OOM (Requested array size exceeds VM limit) issue
[ https://issues.apache.org/jira/browse/SOLR-5661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Raintung Li updated SOLR-5661: -- Attachment: patch-5661.txt add the protection logic. PriorityQueue has OOM (Requested array size exceeds VM limit) issue --- Key: SOLR-5661 URL: https://issues.apache.org/jira/browse/SOLR-5661 Project: Solr Issue Type: Bug Components: contrib - Solr Cell (Tika extraction) Affects Versions: 4.3.1, 4.4, 4.5, 4.5.1, 4.6 Environment: JDK 7 Reporter: Raintung Li Attachments: patch-5661.txt It look like JDK7 change the design for max_array_length logic, it isn't max_jint, and it should be max_jint - header_size(type). If you deliver the Integer.MaxValue to create the PriorityQueue and have enough memory, you will find it is ok in JVM6 but not work in JVM7. JVM7 will throw OOM error while do array rang checking. It should the compatible issue between JVM6 and JVM7. Maybe need protect in the code logic, throw OOM look like big issues for customer. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5477) Async execution of OverseerCollectionProcessor tasks
[ https://issues.apache.org/jira/browse/SOLR-5477?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Anshum Gupta updated SOLR-5477: --- Attachment: SOLR-5477.patch * Limited the size of tracking data structures. * Shutdown the ThreadPoolExectutor. * Fixed tests * Other changes - Naming, indentation, thread safety etc. It's almost there. TODO: * More tests * Handle CoreAdmin failures at OCP end a little better. Async execution of OverseerCollectionProcessor tasks Key: SOLR-5477 URL: https://issues.apache.org/jira/browse/SOLR-5477 Project: Solr Issue Type: Sub-task Components: SolrCloud Reporter: Noble Paul Assignee: Anshum Gupta Attachments: SOLR-5477-CoreAdminStatus.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch, SOLR-5477.patch Typical collection admin commands are long running and it is very common to have the requests get timed out. It is more of a problem if the cluster is very large.Add an option to run these commands asynchronously add an extra param async=true for all collection commands the task is written to ZK and the caller is returned a task id. as separate collection admin command will be added to poll the status of the task command=statusid=7657668909 if id is not passed all running async tasks should be listed A separate queue is created to store in-process tasks . After the tasks are completed the queue entry is removed. OverSeerColectionProcessor will perform these tasks in multiple threads -- This message was sent by Atlassian JIRA (v6.1.5#6160) - 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_60-ea-b03) - Build # 9227 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/9227/ Java: 32bit/jdk1.7.0_60-ea-b03 -server -XX:+UseParallelGC All tests passed Build Log: [...truncated 30545 lines...] -check-forbidden-base: [forbidden-apis] Reading bundled API signatures: jdk-unsafe-1.7 [forbidden-apis] Reading bundled API signatures: jdk-deprecated-1.7 [forbidden-apis] Reading bundled API signatures: commons-io-unsafe-2.1 [forbidden-apis] Reading API signatures: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/base.txt [forbidden-apis] Reading API signatures: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/lucene/tools/forbiddenApis/servlet-api.txt [forbidden-apis] Loading classes to check... [forbidden-apis] Scanning for API signatures and dependencies... [forbidden-apis] Forbidden method invocation: java.lang.String#toUpperCase() [Uses default locale] [forbidden-apis] in org.apache.solr.schema.AbstractSpatialFieldType (AbstractSpatialFieldType.java:95) [forbidden-apis] Scanned 2047 (and 1343 related) class file(s) for forbidden API invocations (in 1.48s), 1 error(s). BUILD FAILED /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/build.xml:453: The following error occurred while executing this line: /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/solr/build.xml:271: The following error occurred while executing this line: /mnt/ssd/jenkins/workspace/Lucene-Solr-trunk-Linux/solr/common-build.xml:474: Check for forbidden API calls failed, see log. Total time: 51 minutes 44 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 32bit/jdk1.7.0_60-ea-b03 -server -XX:+UseParallelGC Archiving artifacts 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
[jira] [Commented] (LUCENE-5395) Upgrade Spatial4j to 0.4
[ https://issues.apache.org/jira/browse/LUCENE-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881646#comment-13881646 ] ASF subversion and git services commented on LUCENE-5395: - Commit 1561250 from [~dsmiley] in branch 'dev/trunk' [ https://svn.apache.org/r1561250 ] LUCENE-5395: use Locale.ROOT Upgrade Spatial4j to 0.4 Key: LUCENE-5395 URL: https://issues.apache.org/jira/browse/LUCENE-5395 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.7 Attachments: LUCENE-5395_Spatial4j_0_4.patch, LUCENE-5395_Spatial4j_0_4.patch Spatial4j 0.4 should be released the week of January 13th; a snapshot is published. A longer version of the delta from 0.4 is in [CHANGES.md|https://github.com/spatial4j/spatial4j/blob/master/CHANGES.md] A couple notable new features are: * Built-in WKT parser without relying on JTS. The older shape string format is deprecated. * A binary shape codec for reading writing the shapes to a byte-stream in a reasonably compact manner. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5395) Upgrade Spatial4j to 0.4
[ https://issues.apache.org/jira/browse/LUCENE-5395?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881647#comment-13881647 ] ASF subversion and git services commented on LUCENE-5395: - Commit 1561251 from [~dsmiley] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1561251 ] LUCENE-5395: use Locale.ROOT Upgrade Spatial4j to 0.4 Key: LUCENE-5395 URL: https://issues.apache.org/jira/browse/LUCENE-5395 Project: Lucene - Core Issue Type: Improvement Components: modules/spatial Reporter: David Smiley Assignee: David Smiley Fix For: 4.7 Attachments: LUCENE-5395_Spatial4j_0_4.patch, LUCENE-5395_Spatial4j_0_4.patch Spatial4j 0.4 should be released the week of January 13th; a snapshot is published. A longer version of the delta from 0.4 is in [CHANGES.md|https://github.com/spatial4j/spatial4j/blob/master/CHANGES.md] A couple notable new features are: * Built-in WKT parser without relying on JTS. The older shape string format is deprecated. * A binary shape codec for reading writing the shapes to a byte-stream in a reasonably compact manner. -- This message was sent by Atlassian JIRA (v6.1.5#6160) - 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.7.0_60-ea-b03) - Build # 9227 - Still Failing!
Fixed. (Yes I do know about ant precommit... but long story never mind why these problems happenned.) - Author: http://www.packtpub.com/apache-solr-3-enterprise-search-server/book -- View this message in context: http://lucene.472066.n3.nabble.com/JENKINS-Lucene-Solr-trunk-Linux-32bit-jdk1-7-0-51-Build-9224-Failure-tp4113340p4113397.html Sent from the Lucene - Java Developer mailing list archive at Nabble.com. - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5578) unable to deploy on wildfly cr1
[ https://issues.apache.org/jira/browse/SOLR-5578?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13881662#comment-13881662 ] Qin Ding commented on SOLR-5578: I got the same error on Debian Wheezy. Wildfly 8.0.0.CR1 + Java 1.7.0_45 + solr-4.6.0.war unable to deploy on wildfly cr1 --- Key: SOLR-5578 URL: https://issues.apache.org/jira/browse/SOLR-5578 Project: Solr Issue Type: Bug Affects Versions: 4.6 Environment: Wildfly 8.0.0.CR1 with Java 1.7.0_45 on Ubuntu 13.10 Reporter: Michael Cramer we are unable to deploy the solr.war on wildfly 8.0.0.CR1 while the Beat versions work fine. Trace is following while deploying: 2013-12-24 11:48:49,221 WARN [org.jboss.modules] (weld-worker-6) Failed to define class org.apache.hadoop.hdfs.web.resources.UserProvider in Module deployment.solr.wa r:main from Service Module Loader: java.lang.LinkageError: Failed to link org/apache/hadoop/hdfs/web/resources/UserProvider (Module deployment.solr.war:main from Ser vice Module Loader) at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:428) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ModuleClassLoader.loadClassLocal(ModuleClassLoader.java:261) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ModuleClassLoader$1.loadClassLocal(ModuleClassLoader.java:76) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.Module.loadModuleClass(Module.java:548) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:189) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ConcurrentClassLoader.loadClass(ConcurrentClassLoader.java:118) [jboss-modules.jar:1.3.0.Final] at org.jboss.as.weld.WeldModuleResourceLoader.classForName(WeldModuleResourceLoader.java:68) [wildfly-weld-8.0.0.CR1.jar:8.0.0.CR1] at org.jboss.weld.bootstrap.BeanDeployer.loadClass(BeanDeployer.java:106) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59] at org.jboss.weld.bootstrap.BeanDeployer.addClass(BeanDeployer.java:94) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59] at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:62) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59] at org.jboss.weld.bootstrap.ConcurrentBeanDeployer$1.doWork(ConcurrentBeanDeployer.java:60) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59] at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59] at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53) [weld-core-impl-2.1.1.Final.jar:2013-12-03 09:59] at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_45] at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_45] at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_45] at java.lang.Thread.run(Thread.java:744) [rt.jar:1.7.0_45] Caused by: java.lang.NoClassDefFoundError: com/sun/jersey/spi/inject/InjectableProvider at java.lang.ClassLoader.defineClass1(Native Method) [rt.jar:1.7.0_45] at java.lang.ClassLoader.defineClass(ClassLoader.java:800) [rt.jar:1.7.0_45] at org.jboss.modules.ModuleClassLoader.doDefineOrLoadClass(ModuleClassLoader.java:345) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ModuleClassLoader.defineClass(ModuleClassLoader.java:423) [jboss-modules.jar:1.3.0.Final] ... 19 more Caused by: java.lang.ClassNotFoundException: com.sun.jersey.spi.inject.InjectableProvider from [Module deployment.solr.war:main from Service Module Loader] at org.jboss.modules.ModuleClassLoader.findClass(ModuleClassLoader.java:197) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ConcurrentClassLoader.performLoadClassUnchecked(ConcurrentClassLoader.java:443) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ConcurrentClassLoader.performLoadClassChecked(ConcurrentClassLoader.java:431) [jboss-modules.jar:1.3.0.Final] at org.jboss.modules.ConcurrentClassLoader.performLoadClass(ConcurrentClassLoader.java:373)
