[jira] [Created] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
Manuel Amoabeng created LUCENE-5166: --- Summary: PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1373#comment-1373 ] Manuel Amoabeng edited comment on LUCENE-5166 at 8/12/13 7:42 AM: -- java.lang.IndexOutOfBoundsException: start , end 10004, s.length() 1 at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:453) at java.lang.StringBuilder.append(StringBuilder.java:179) at org.apache.lucene.search.postingshighlight.DefaultPassageFormatter.append(DefaultPassageFormatter.java:135) at org.apache.lucene.search.postingshighlight.DefaultPassageFormatter.format(DefaultPassageFormatter.java:79) at org.apache.lucene.search.postingshighlight.PostingsHighlighter.highlightField(PostingsHighlighter.java:435) at org.apache.lucene.search.postingshighlight.PostingsHighlighter.highlightFields(PostingsHighlighter.java:353) at org.apache.lucene.search.postingshighlight.PostingsHighlighter.highlightFields(PostingsHighlighter.java:268) was (Author: mamoabeng): java.lang.IndexOutOfBoundsException: start , end 10004, s.length() 1 at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:453) at java.lang.StringBuilder.append(StringBuilder.java:179) at org.apache.lucene.search.postingshighlight.DefaultPassageFormatter.append(DefaultPassageFormatter.java:135) at com.vjoon.ps.core.ftquery.business.index.LuceneIndexer$1$1.append(LuceneIndexer.java:252) at org.apache.lucene.search.postingshighlight.DefaultPassageFormatter.format(DefaultPassageFormatter.java:79) at org.apache.lucene.search.postingshighlight.PostingsHighlighter.highlightField(PostingsHighlighter.java:435) at org.apache.lucene.search.postingshighlight.PostingsHighlighter.highlightFields(PostingsHighlighter.java:353) at org.apache.lucene.search.postingshighlight.PostingsHighlighter.highlightFields(PostingsHighlighter.java:268) PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=1373#comment-1373 ] Manuel Amoabeng commented on LUCENE-5166: - java.lang.IndexOutOfBoundsException: start , end 10004, s.length() 1 at java.lang.AbstractStringBuilder.append(AbstractStringBuilder.java:453) at java.lang.StringBuilder.append(StringBuilder.java:179) at org.apache.lucene.search.postingshighlight.DefaultPassageFormatter.append(DefaultPassageFormatter.java:135) at com.vjoon.ps.core.ftquery.business.index.LuceneIndexer$1$1.append(LuceneIndexer.java:252) at org.apache.lucene.search.postingshighlight.DefaultPassageFormatter.format(DefaultPassageFormatter.java:79) at org.apache.lucene.search.postingshighlight.PostingsHighlighter.highlightField(PostingsHighlighter.java:435) at org.apache.lucene.search.postingshighlight.PostingsHighlighter.highlightFields(PostingsHighlighter.java:353) at org.apache.lucene.search.postingshighlight.PostingsHighlighter.highlightFields(PostingsHighlighter.java:268) PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-MacOSX (64bit/jdk1.7.0) - Build # 704 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-MacOSX/704/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC 1 tests failed. REGRESSION: org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic Error Message: Connect to 127.0.0.1:52308 timed out Stack Trace: org.apache.http.conn.ConnectTimeoutException: Connect to 127.0.0.1:52308 timed out at __randomizedtesting.SeedInfo.seed([A190F8CDEA86504D:A6AE5D8355AD663]:0) at org.apache.http.conn.scheme.PlainSocketFactory.connectSocket(PlainSocketFactory.java:129) at org.apache.http.impl.conn.DefaultClientConnectionOperator.openConnection(DefaultClientConnectionOperator.java:180) at org.apache.http.impl.conn.ManagedClientConnectionImpl.open(ManagedClientConnectionImpl.java:294) at org.apache.http.impl.client.DefaultRequestDirector.tryConnect(DefaultRequestDirector.java:645) at org.apache.http.impl.client.DefaultRequestDirector.execute(DefaultRequestDirector.java:480) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:906) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:805) at org.apache.http.impl.client.AbstractHttpClient.execute(AbstractHttpClient.java:784) at org.apache.lucene.replicator.http.HttpClientBase.executeGET(HttpClientBase.java:178) at org.apache.lucene.replicator.http.HttpReplicator.checkForUpdate(HttpReplicator.java:51) at org.apache.lucene.replicator.ReplicationClient.doUpdate(ReplicationClient.java:196) at org.apache.lucene.replicator.ReplicationClient.updateNow(ReplicationClient.java:402) at org.apache.lucene.replicator.http.HttpReplicatorTest.testBasic(HttpReplicatorTest.java:114) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:606) at com.carrotsearch.randomizedtesting.RandomizedRunner.invoke(RandomizedRunner.java:1559) at com.carrotsearch.randomizedtesting.RandomizedRunner.access$600(RandomizedRunner.java:79) at com.carrotsearch.randomizedtesting.RandomizedRunner$6.evaluate(RandomizedRunner.java:737) at com.carrotsearch.randomizedtesting.RandomizedRunner$7.evaluate(RandomizedRunner.java:773) at com.carrotsearch.randomizedtesting.RandomizedRunner$8.evaluate(RandomizedRunner.java:787) at org.apache.lucene.util.TestRuleSetupTeardownChained$1.evaluate(TestRuleSetupTeardownChained.java:50) at org.apache.lucene.util.TestRuleFieldCacheSanity$1.evaluate(TestRuleFieldCacheSanity.java:51) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at org.apache.lucene.util.TestRuleThreadAndTestName$1.evaluate(TestRuleThreadAndTestName.java:49) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgnoreAfterMaxFailures.java:70) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at com.carrotsearch.randomizedtesting.ThreadLeakControl$StatementRunner.run(ThreadLeakControl.java:358) at com.carrotsearch.randomizedtesting.ThreadLeakControl.forkTimeoutingTask(ThreadLeakControl.java:782) at com.carrotsearch.randomizedtesting.ThreadLeakControl$3.evaluate(ThreadLeakControl.java:442) at com.carrotsearch.randomizedtesting.RandomizedRunner.runSingleTest(RandomizedRunner.java:746) at com.carrotsearch.randomizedtesting.RandomizedRunner$3.evaluate(RandomizedRunner.java:648) at com.carrotsearch.randomizedtesting.RandomizedRunner$4.evaluate(RandomizedRunner.java:682) at com.carrotsearch.randomizedtesting.RandomizedRunner$5.evaluate(RandomizedRunner.java:693) at org.apache.lucene.util.AbstractBeforeAfterRule$1.evaluate(AbstractBeforeAfterRule.java:46) at org.apache.lucene.util.TestRuleStoreClassName$1.evaluate(TestRuleStoreClassName.java:42) at com.carrotsearch.randomizedtesting.rules.SystemPropertiesInvariantRule$1.evaluate(SystemPropertiesInvariantRule.java:55) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.NoShadowingOrOverridesOnMethodsRule$1.evaluate(NoShadowingOrOverridesOnMethodsRule.java:39) at com.carrotsearch.randomizedtesting.rules.StatementAdapter.evaluate(StatementAdapter.java:36) at
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736684#comment-13736684 ] Mikhail Khludnev commented on SOLR-3076: [~ysee...@gmail.com] give me last chance to rescue -the world- Solr. # introduce SolrIndexSearcher.addCache(name), QParser can add usercache itself. # leave it as it was before, BJQParser allows to specify user cache for storing CachingWrapperFilter, otherwise it performs bad. It seems forgivable for the 'early-adopter' feature. Solr(Cloud) should support block joins -- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Assignee: Yonik Seeley Fix For: 4.5, 5.0 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manuel Amoabeng updated LUCENE-5166: Attachment: LUCENE-5166.patch PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736705#comment-13736705 ] Shai Erera commented on LUCENE-5166: Can you show a real usecase for a document matching beyond content.length()? Your patch artificially creates an out-of-bound Passage, but I think it's better if we can see a real usecase, e.g. maybe a combination of TokenFilters may cause that? But if e.g. the app indexed content1 but then tries to highlight content2, I don't think that's a supported usecase... PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5092) join: don't expect all filters to be FixedBitSet instances
[ https://issues.apache.org/jira/browse/LUCENE-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736713#comment-13736713 ] Uwe Schindler commented on LUCENE-5092: --- [~mkhludnev]: I understand the problem because it depends of the type of query toChild or toParent. The suggestion here was to somehow recapitulate why the block joining was done like that. Maybe we can optimize it or add additional metadata to the documents in the block so we make it easier to go from childs to parent and vice versa. join: don't expect all filters to be FixedBitSet instances -- Key: LUCENE-5092 URL: https://issues.apache.org/jira/browse/LUCENE-5092 Project: Lucene - Core Issue Type: Improvement Components: modules/join Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-5092.patch The join module throws exceptions when the parents filter isn't a FixedBitSet. The reason is that the join module relies on prevSetBit to find the first child document given a parent ID. As suggested by Uwe and Paul Elschot on LUCENE-5081, we could fix it by exposing methods in the iterators to iterate backwards. When the join modules gets an iterator which isn't able to iterate backwards, it would just need to dump its content into another DocIdSet that supports backward iteration, FixedBitSet for example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5136) New discovery mode ignores instanceDir property
Thomas Scheffler created SOLR-5136:
--
Summary: New discovery mode ignores instanceDir property
Key: SOLR-5136
URL: https://issues.apache.org/jira/browse/SOLR-5136
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.4
Environment: Linux
Reporter: Thomas Scheffler
I have a common instance directory to share {{schema.xml}} and
{{solrconfig.xml}} between multiple cores. According to [Core Discovery (4.4
and
beyond)|http://wiki.apache.org/solr/Core%20Discovery%20%284.4%20and%20beyond%29]
a property *instanceDir* is available to set the instance directory for the
configured core.
On start up of SOLR instanceDir is always set to the parent directory of
_core.properties_.
Setting a complete path to {{schema.xml}} and {{solrconfig.xml}} via *schema*
and *config* properties won't help as every relative path is resolved against
the wrong (unconfigurable) instanceDir and not against {{schema.xml}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Manuel Amoabeng updated LUCENE-5166: Attachment: LUCENE-5166-2.patch PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736726#comment-13736726 ] Manuel Amoabeng commented on LUCENE-5166: - Please find attached another test case. It is sort of bad luck to run into this in a real use case but it actually happened to me. PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[
https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736744#comment-13736744
]
Robert Muir commented on SOLR-3076:
---
{quote}
Since no one seems to have issues with any of the important parts like
the public APIs, I plan on committing this shortly.
{quote}
Uhhh, the code is important to some of us too. There are several objections
listed on this issue.
The patches contributed here took lucene's join module and integrated it into
solr, actually thats the description of the issue Lucene has the ability to do
block joins, we should add it to Solr..
But then suddenly the code becomes garbage: your patch *FORKS CODE OF ENTIRE
LUCENE JOIN MODULE* to make it slow and top-level. Why even bring in
lucene-join.jar here?
So yeah, i dont care if you think code is important or not, -1 to this.
Solr(Cloud) should support block joins
--
Key: SOLR-3076
URL: https://issues.apache.org/jira/browse/SOLR-3076
Project: Solr
Issue Type: New Feature
Reporter: Grant Ingersoll
Assignee: Yonik Seeley
Fix For: 4.5, 5.0
Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png,
bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch,
child-bjqparser.patch, dih-3076.patch, dih-config.xml,
parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at
1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-7036-childDocs-solr-fork-trunk-patched,
solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch,
tochild-bjq-filtered-search-fix.patch
Lucene has the ability to do block joins, we should add it to Solr.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736753#comment-13736753 ] Michael McCandless commented on SOLR-3076: -- bq. I plan on committing this shortly. Please don't. Three people have objections to the approach here ... let's iterate to a solution others are happy with. Solr(Cloud) should support block joins -- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Assignee: Yonik Seeley Fix For: 4.5, 5.0 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5162) TestBlockJoinSorting.testNestedSorting asset fails
[
https://issues.apache.org/jira/browse/LUCENE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Martijn van Groningen resolved LUCENE-5162.
---
Resolution: Fixed
Assignee: Martijn van Groningen
Ported the test fix to 4.3 branch.
TestBlockJoinSorting.testNestedSorting asset fails
---
Key: LUCENE-5162
URL: https://issues.apache.org/jira/browse/LUCENE-5162
Project: Lucene - Core
Issue Type: Bug
Components: core/other
Affects Versions: 4.3.1
Reporter: Mikhail Khludnev
Assignee: Martijn van Groningen
Priority: Minor
ant test -Dtestcase=TestBlockJoinSorting -Dtests.method=testNestedSorting
-Dtests.seed=FB4F1BE85579255B -Dtests.slow=true -Dtests.locale=da_DK
-Dtests.timezone=Asia/Qatar -Dtests.file.encoding=UTF-8
[junit4:junit4] FAILURE 0.86s | TestBlockJoinSorting.testNestedSorting
[junit4:junit4] Throwable #1: java.lang.AssertionError: expected:3 but
was:28
[junit4:junit4] at
__randomizedtesting.SeedInfo.seed([FB4F1BE85579255B:F3A6F6A915D02835]:0)
[junit4:junit4] at
org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting(TestBlockJoinSorting.java:226)
[junit4:junit4] at java.lang.Thread.run(Thread.java:680)
[junit4:junit4] 2 NOTE: test params are: codec=Asserting,
sim=RandomSimilarityProvider(queryNorm=true,coord=crazy): {}, locale=da_DK,
timezone=Asia/Qatar
[junit4:junit4]
[junit4:junit4] Tests with failures:
[junit4:junit4] -
org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3076) Solr(Cloud) should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-3076: --- Assignee: (was: Yonik Seeley) Solr(Cloud) should support block joins -- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 4.5, 5.0 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736774#comment-13736774 ] Yonik Seeley commented on SOLR-3076: Ah, the joy of lucene vs solr politics. Anyway, I'm out of time on this issue that I worked hard to get committable (and I was about to commit... it's too bad we're letting perfect be the enemy of good here, but I feel it's a hell of a lot more political than technical). Solr(Cloud) should support block joins -- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Assignee: Yonik Seeley Fix For: 4.5, 5.0 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736776#comment-13736776 ] Yonik Seeley commented on SOLR-3076: bq. BJQParser allows to specify user cache for storing CachingWrapperFilter I don't think that should be part of the parser API (or did you just mean just as config in solrconfig.xml?) Solr(Cloud) should support block joins -- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 4.5, 5.0 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736781#comment-13736781 ] Mikhail Khludnev commented on SOLR-3076: bq. just mean just as config in solrconfig.xml yep. Solr(Cloud) should support block joins -- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 4.5, 5.0 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736784#comment-13736784 ] Shai Erera commented on LUCENE-5166: Interesting. FYI, I will not be available in the next 2 weeks, and haven't reproduced it yet. If no one assigns himself to the issue, I will when I'm back. PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736785#comment-13736785 ] Robert Muir commented on LUCENE-5166: - I have reproduced it with Manuel's test PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5166: Attachment: LUCENE-5166.patch Attached is just a combined patch of Manuel's 2 patches. There is definitely bug(s) here. As far as the fix, to me the big question (I put it in a nocommit to his test case), is if formatter classes should really have to deal with these cases. PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[
https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736790#comment-13736790
]
Michael McCandless commented on SOLR-3076:
--
{quote}
I decided it was
best to leave per-segment filters for a different issue and create queries
that would work well with the way Solr currently does it's filter caching
and request construction.
{quote}
I think that makes sense (decouple the two), but can we do this without forking
lucene/join's *BlockJoinQuery?
E.g. maybe instead of requiring a FixedBitSet, Parent/ChildBlockJoinQuery could
accept an interface/abstract class, that a slice of OpenBitSet (and
FixedBitSet) could implement?
Or ... messy, but maybe it could work maybe: the *BlockJoinQuery could do an
instanceof check + cast for this OpenBitSet slice ...
Solr(Cloud) should support block joins
--
Key: SOLR-3076
URL: https://issues.apache.org/jira/browse/SOLR-3076
Project: Solr
Issue Type: New Feature
Reporter: Grant Ingersoll
Fix For: 4.5, 5.0
Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png,
bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch,
child-bjqparser.patch, dih-3076.patch, dih-config.xml,
parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at
1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-7036-childDocs-solr-fork-trunk-patched,
solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch,
tochild-bjq-filtered-search-fix.patch
Lucene has the ability to do block joins, we should add it to Solr.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5136) New discovery mode ignores instanceDir property
[
https://issues.apache.org/jira/browse/SOLR-5136?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Erick Erickson resolved SOLR-5136.
--
Resolution: Not A Problem
From that very page:
This is being debated, it may not be allowed and the instanceDir may be the
directory in which core.properties is found
The place this is going Real Soon Now is configuration sets that allow you to
share the configuration data in a common directory.
I'll update the page to remove that since it's stale information. For the time
being you'll have to copy the data to each discovered core.
New discovery mode ignores instanceDir property
---
Key: SOLR-5136
URL: https://issues.apache.org/jira/browse/SOLR-5136
Project: Solr
Issue Type: Bug
Components: multicore
Affects Versions: 4.4
Environment: Linux
Reporter: Thomas Scheffler
I have a common instance directory to share {{schema.xml}} and
{{solrconfig.xml}} between multiple cores. According to [Core Discovery (4.4
and
beyond)|http://wiki.apache.org/solr/Core%20Discovery%20%284.4%20and%20beyond%29]
a property *instanceDir* is available to set the instance directory for the
configured core.
On start up of SOLR instanceDir is always set to the parent directory of
_core.properties_.
Setting a complete path to {{schema.xml}} and {{solrconfig.xml}} via *schema*
and *config* properties won't help as every relative path is resolved against
the wrong (unconfigurable) instanceDir and not against {{schema.xml}}.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736799#comment-13736799 ] Yonik Seeley commented on SOLR-3076: bq. FORKS CODE OF ENTIRE LUCENE JOIN MODULE I really wanted to stop participating in discussions like this, but then I thought that it was important to clear up this mischaracterization for casual viewers. The patch introduced custom versions of *2* top level query classes (ToChildBlockJoinQuery and ToParentBlockJoinQuery). Further, they were package private implementation details. Focusing on whether the classes are officially part of the lucene join module are silly - it should be irrelevant to Solr end users... you could change those class names every day and it just wouldn't matter. Solr(Cloud) should support block joins -- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 4.5, 5.0 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736800#comment-13736800 ] Michael McCandless commented on LUCENE-5166: I think we shouldn't send out of bounds matches to the formatter? Because all it can do is bounds check and skip it? I think maybe we also shouldn't even send the passage if it was truncated, even if some matches were before the truncation? PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5166: Attachment: LUCENE-5166.patch OK here's a patch. the cause of the bug is that we only know startOffsets are always increasing (the algorithm relies on this, and merges them across terms). So we cannot safely terminate when end = limit (only start = limit), but we don't have to confuse the formatter with the cases of terms that 'span' the limit. PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-791) Allow to submit config and schema when creating a new core
[
https://issues.apache.org/jira/browse/SOLR-791?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736825#comment-13736825
]
Hooman Mozaffari commented on SOLR-791:
---
As an alternative you can extend ??CoreAdminHandler?? class, overwrite
??handleCustomAction?? method and implement the extra functionality.
In Solr 4.4.0 and later make sure you have introduced your custom core admin
handler by setting up the following attributes in ??solr.xml??:
{code:xml}
str name=sharedLib[location of your shared libraries including the jar file
containing your new admin handler class]/str
str name=adminHandler[fully qualified name of your new admin handler
class]/str
{code}
Allow to submit config and schema when creating a new core
--
Key: SOLR-791
URL: https://issues.apache.org/jira/browse/SOLR-791
Project: Solr
Issue Type: New Feature
Components: clients - java
Affects Versions: 1.3
Reporter: Gunnar Wagenknecht
Currently it's possible to create cores remotely via SolrJ.
{code}
CoreAdminRequest.createCore(acore, acoreinstancedir, adminServer);
{code}
However, this process is incomplete because I need to manually log onto the
remote server and place a configuration file as well as a schema file into
the {{conf/}} folder in the {{acoreinstancedir/}}. It would be great it I can
simply submit those files together with the create core request.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736830#comment-13736830 ] Uwe Schindler commented on SOLR-3076: - Hi, I don't think we should again start with bq. Ah, the joy of lucene vs solr politics again! As far as I understand, the current issue is: Solr has no way to cache filters per segment, so Yonik forked the whole (or major parts) of the Lucene join module into the source code of Solr. This also includes using OpenBitSet instead of FixedBitSet (why?). I would suggest to proceed like this: - Delay committing for now - Open new issue to allow per-segment caches in Solr - Open new issue to move away from OpenBitSet as a requirement for caching filters in Solr. For filter caching, FixedBitSet is the better alternative, as filters always have a fixed number of documents. Also reuse CachingWrapperFilter in Solr and don't have a separate filter caching. This would also allow to use the new Bitset implementations in Solr that were recently added to Lucene. Solr should simply have a non-implementation-agnostic caching for DocIdSets. - Once this is committed, adapt the current patch to use the new filter caching. From what I have learned in the past: Once we have the forked code in Solr there is no way to move away from it, mainly because: - Backwards compatibility complaints of plugin authors - It's already implemented and working - why change? - Some people claim that Top-level caches are not slow. So my clear -1 from committing the forked code and delay it a few more weeks and instead fix the dependent issues as noted above before this one. Solr(Cloud) should support block joins -- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 4.5, 5.0 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736924#comment-13736924 ] Michael McCandless commented on LUCENE-5166: Hmm so this means we may pick a truncated passage to present? I suppose it's unlikely to score well ... just seems bad though. Wait, couldn't we fix passageQueue.offer(current) to not offer it if current.endOffset == contentLength? PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736929#comment-13736929 ] Robert Muir commented on LUCENE-5166: - Well the passage may not be truncated: for example depending on the analyzer (e.g. ngrams or something), it could just be that the term spans sentences. And the problem is: only startOffset is guaranteed to be increasing. so if we discard the passage just because of this, it could be unsafe since new terms that are in bounds have still yet to be seen... PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5166: Attachment: LUCENE-5166.patch Improved patch, thank you Mike :) PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5137) Allow localizable fields to be mapped by a map
Petar Tahchiev created SOLR-5137:
Summary: Allow localizable fields to be mapped by a map
Key: SOLR-5137
URL: https://issues.apache.org/jira/browse/SOLR-5137
Project: Solr
Issue Type: Improvement
Reporter: Petar Tahchiev
Priority: Minor
Hello everybody,
I am using SolrJ and I would really appreaciate if there was an annotation that
maps the localizable fields in a map of Locale, String. Just like this:
{code}
public class Product {
@LocaleField
private MapLocale, String name;
}
{code}
instead of
{code}
public class Product {
@Field
private String name_en;
@Field
private String name_fr;
@Field
private String name_de;
//etc
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael McCandless updated LUCENE-5166: --- Attachment: LUCENE-5166.patch I'm still confused about how we handle the truncated passage ... I added a [failing] test but maybe the test is bogus? PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[
https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736966#comment-13736966
]
Robert Muir commented on LUCENE-5166:
-
Well the patch doesnt attempt to change anything about the breakiterator logic:
so your test is valid but testing something different.
Let me try to explain:
The bug Manuel found here is matching term spanning the content boundary. so
lets call this truncated term. This patch fixes this so formatter doesnt have
to deal with it, and there is no AIOOBE or strange checks in the formatter.
The test you write is for different behavior: it saying, if the passage itself
spans the content boundary, don't present it to the formatter at all. But, this
is sorta a different issue, its already handled here today by Math.min and the
formatter never has to deal with it:
{code}
// advance breakiterator
assert BreakIterator.DONE 0;
current.startOffset = Math.max(bi.preceding(start+1), 0);
current.endOffset = Math.min(bi.next(), contentLength);
{code}
If we want to change the behavior for this, thats cool too, but its not really
related to the bug at hand. I am not opposed to fixing it, but one problem
would be someone using stuff like WholeBreakIterator, though we could solve
it in a different way by having WholeBreakIterator take in the limit itself (I
dont know if this would address your concern though).
PostingsHighlighter fails with IndexOutOfBoundsException
Key: LUCENE-5166
URL: https://issues.apache.org/jira/browse/LUCENE-5166
Project: Lucene - Core
Issue Type: Bug
Components: modules/highlighter
Affects Versions: 4.4
Reporter: Manuel Amoabeng
Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch,
LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch
Given a document with a match at a startIndex PostingsHighlighter.maxlength
and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will
throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is
invoked.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736971#comment-13736971 ] Michael McCandless commented on LUCENE-5166: OK let's not try to address that on this issue ... I'm not even sure it needs fixing. It ought to be rare-ish that a truncated passage is selected. PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736975#comment-13736975 ] Elran Dvir commented on SOLR-5084: -- Thank you all very much for your very quick feedback. @Hoss, 1) I eliminated all formatting changes and attached a new patch. I hope it'll be more readable now. 2) I will try to create unit test as soon as possible and attach it. 3) I returned the value as EnumFieldValue in JavaBin format because I would like to allow for a use case of sorting the values when returned to my application by SolrJ. 4) Maybe it could, but I tried to keep the implementation simple and it didn’t appear to give much more value. If someone feels strongly about it I can revisit the implementation @Robert, In the configuration, I chose to specify the numeric values because I want to also enable indexing and querying numeric values. For example, the queries risk:[1 TO 3] and risk:[Low TO High] are both valid. Currently: - If a bogus string value is sent, the value is indexed as -1. - If a bogus integer value is sent, if the value is not a negative number, the value is indexed as is. If it’s negative – the value is indexed as -1. - The display value is of course string. If we don’t find a matching label to the numeric value in the configuration, the actual numeric value is displayed. Adding a new value at the end, would work. Changing a display string for a value, will also work for retrieving data – new data will have to be inserted using the new name (or by int value) Removing a legal value from the list would retrieve the numeric value for existing data I have no use case for removing a previously legal value, so I can either document the behavior, or implement a different behavior – depending on how this discussion goes @Erick, I didn't intend to make this type single valued on purpose, it’s just that my use case is single valued. I changed the field's configuration to multi value and it seems to work fine (facet, pivot, stats, return stored field). Why do you say the assumption is the type is restricted to single value? Thanks again. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5084) new field type - EnumField
[ https://issues.apache.org/jira/browse/SOLR-5084?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13736990#comment-13736990 ] Elran Dvir commented on SOLR-5084: -- I failed attaching the new patch. I will attach it ASAP. The only changes are formatting. new field type - EnumField -- Key: SOLR-5084 URL: https://issues.apache.org/jira/browse/SOLR-5084 Project: Solr Issue Type: New Feature Reporter: Elran Dvir Attachments: enumsConfig.xml, schema_example.xml, Solr-5084.patch, Solr-5084.patch We have encountered a use case in our system where we have a few fields (Severity. Risk etc) with a closed set of values, where the sort order for these values is pre-determined but not lexicographic (Critical is higher than High). Generically this is very close to how enums work. To implement, I have prototyped a new type of field: EnumField where the inputs are a closed predefined set of strings in a special configuration file (similar to currency.xml). The code is based on 4.2.1. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5167) SimilarityBase does not pass docId in the score method for use of FieldCache or DocValues
Ross Woolf created LUCENE-5167: -- Summary: SimilarityBase does not pass docId in the score method for use of FieldCache or DocValues Key: LUCENE-5167 URL: https://issues.apache.org/jira/browse/LUCENE-5167 Project: Lucene - Core Issue Type: Bug Components: core/query/scoring Affects Versions: 4.3.1, 4.4, 4.2, 4.1, 4.0 Reporter: Ross Woolf SimilarityBase does not pass docId in the score method for use of FieldCache or DocValues. If the intent of extending SimilarityBase is to use a FieldCache or NumericDocValuesField as part of the scoring, this is not possible because SimilarityBase does not pass on the docId as one of the parameters of the score method. This parameter should be added to the score method so that fieldCache or NumericDocValues can be used when extending SimilarityBase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5167) SimilarityBase does not pass docId in the score method for use of FieldCache or DocValues
[ https://issues.apache.org/jira/browse/LUCENE-5167?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737026#comment-13737026 ] Robert Muir commented on LUCENE-5167: - Thanks for opening the issue Ross, I looked, the trickier part seems to be how to allow the users of this to get AtomicReader on each segment transition. Currently, the idea is SimilarityBase hides a lot of this complexity (presents a simple stateless API over the more advanced stateful api): but in addition to passing docid, users will need a way to grab things like DocValues from each segment to make it useful... SimilarityBase does not pass docId in the score method for use of FieldCache or DocValues - Key: LUCENE-5167 URL: https://issues.apache.org/jira/browse/LUCENE-5167 Project: Lucene - Core Issue Type: Bug Components: core/query/scoring Affects Versions: 4.0, 4.1, 4.2, 4.4, 4.3.1 Reporter: Ross Woolf SimilarityBase does not pass docId in the score method for use of FieldCache or DocValues. If the intent of extending SimilarityBase is to use a FieldCache or NumericDocValuesField as part of the scoring, this is not possible because SimilarityBase does not pass on the docId as one of the parameters of the score method. This parameter should be added to the score method so that fieldCache or NumericDocValues can be used when extending SimilarityBase. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4898) Flesh out the Schema REST API
[
https://issues.apache.org/jira/browse/SOLR-4898?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-4898:
-
Description:
As of Solr 4.4, the Solr Schema Rest API provides read access to all schema
elements (SOLR-4503, SOLR-4658, SOLR-4537, SOLR-4623), and the ability to
dynamically add new fields (SOLR-3251). See the wiki for documentation:
[http://wiki.apache.org/solr/SchemaRESTAPI].
This is an umbrella issue to capture all future additions to the schema REST
API, including:
# adding dynamic fields
# adding field types
# adding copy field directives
# enabling wholesale replacement by PUTing a new schema.
# modifying fields, dynamic fields, field types, and copy field directives
# removing fields, dynamic fields, field types, and copy field directives
# modifying all remaining aspects of the schema: Name, Version, Unique Key,
Global Similarity, and Default Query Operator
I think the first three will be the easiest.
The main use case for further modifications to the Schema API is to offer a new
default schema lifecycle to replace the current schema lifecycle (in which
users manually edit a local copy of schema.xml, then overwrite the
authoritative schema.xml file -- on local disk or in ZooKeeper -- and then
reload or restart Solr), to allow for the schema API to perform all schema edit
operations. It's important to note that the current default schema lifecycle
will continue to be supported, even after it is no longer the default: people
will always be able to directly edit {{schema.xml}}, although if they choose to
do so, they won't be able to use the Schema API methods that modify the schema.
Before Solr can switch the default schema configuration to
{{ManagedIndexSchema}}, which is a prerequisite for all Schema API methods that
modify the schema, everything that the current default schema lifecycle
supports must be supported by the Schema API.
The blocking issue for switching to the default schema configuration to
{{ManagedIndexSchema}}, minimally, is allowing wholesale schema replacement via
the Schema API -- this is essentially support for the current schema lifecycle,
with the additional requirement that users go through the Schema API. The read
side of the schema lifecycle, i.e. getting the current live schema, is already
implemented.
was:
As of Solr 4.4, the Solr Schema Rest API provides read access to all schema
elements (SOLR-4503, SOLR-4658, SOLR-4537, SOLR-4623), and the ability to
dynamically add new fields (SOLR-3251). See the wiki for documentation:
[http://wiki.apache.org/solr/SchemaRESTAPI].
This is an umbrella issue to capture all future additions to the schema REST
API, including:
# adding dynamic fields
# adding field types
# adding copy field directives
# enabling wholesale replacement by PUTing a new schema.
# modifying fields, dynamic fields, field types, and copy field directives
# removing fields, dynamic fields, field types, and copy field directives
# modifying all remaining aspects of the schema: Name, Version, Unique Key,
Global Similarity, and Default Query Operator
I think the first three will be the easiest.
Flesh out the Schema REST API
-
Key: SOLR-4898
URL: https://issues.apache.org/jira/browse/SOLR-4898
Project: Solr
Issue Type: New Feature
Components: Schema and Analysis
Affects Versions: 4.4
Reporter: Steve Rowe
As of Solr 4.4, the Solr Schema Rest API provides read access to all schema
elements (SOLR-4503, SOLR-4658, SOLR-4537, SOLR-4623), and the ability to
dynamically add new fields (SOLR-3251). See the wiki for documentation:
[http://wiki.apache.org/solr/SchemaRESTAPI].
This is an umbrella issue to capture all future additions to the schema REST
API, including:
# adding dynamic fields
# adding field types
# adding copy field directives
# enabling wholesale replacement by PUTing a new schema.
# modifying fields, dynamic fields, field types, and copy field directives
# removing fields, dynamic fields, field types, and copy field directives
# modifying all remaining aspects of the schema: Name, Version, Unique Key,
Global Similarity, and Default Query Operator
I think the first three will be the easiest.
The main use case for further modifications to the Schema API is to offer a
new default schema lifecycle to replace the current schema lifecycle (in
which users manually edit a local copy of schema.xml, then overwrite the
authoritative schema.xml file -- on local disk or in ZooKeeper -- and then
reload or restart Solr), to allow for the schema API to perform all schema
edit operations. It's important to note that the current default schema
lifecycle will continue to be supported, even after it is no longer the
default: people will always be able to directly edit {{schema.xml}},
[jira] [Updated] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-5166: Attachment: LUCENE-5166.patch There was a bug in my patch: I added another unit test for this! I think its ready. PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737057#comment-13737057 ] Michael McCandless commented on LUCENE-5166: +1 Tricky! PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5138) requestHandler (qt) is not passing q when defined in solrconfig.xml
Bill Bell created SOLR-5138: --- Summary: requestHandler (qt) is not passing q when defined in solrconfig.xml Key: SOLR-5138 URL: https://issues.apache.org/jira/browse/SOLR-5138 Project: Solr Issue Type: Bug Affects Versions: 4.5 Environment: OS: Linux 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux SOLR: 4.5-SNAPSHOT 1511470M - 2013-08-07 18:30:52 Reporter: Bill Bell Priority: Critical We have this qt defined: requestHandler name=providerdetails class=solr.SearchHandler lst name=defaults str name=q*:*/str str name=defTypelucene/str str name=echoParamsnone/str str name=wtjson/str /requestHandler When called like this http://localhost:8080/solr/provider/select?echoParams=ALLfq=pwid:xlkm7wt=xmlqt=providerdetails the q does not seem to be recognized and no results are returned unless the q is explicitly set. In SOLR 3.6 the q is seen by the request handler. SOLR 4.5 (4.5-SNAPSHOT 1511470M - 2013-08-07 18:30:52) returns this - note that q=*:* is missing: responselst name=responseHeaderint name=status0/intint name=QTime1/intlst name=paramsstr name=echoParamsALL/strstr name=echoParamsALL/strstr name=qtproviderdetails/strstr name=wtxml/strstr name=fqpwid:xlkm7/str/lst/lstresult name=response numFound=0 start=0//response 3.6.2 returns the following - note q=*:* is shown: lst name=responseHeaderint name=status0/intint name=QTime1/intlst name=paramsstr name=echoParamsALL/strstr name=q*:*/strstr name=wtxml/strstr name=echoParamsALL/strstr name=wtxml/strstr name=qtproviderdetails/strstr name=fqpwid:xlkm7/str/lst/lst -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737101#comment-13737101 ] ASF subversion and git services commented on LUCENE-5166: - Commit 1513207 from [~rcmuir] in branch 'dev/trunk' [ https://svn.apache.org/r1513207 ] LUCENE-5166: PostingsHighlighter fails with IndexOutOfBoundsException PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5138) requestHandler (qt) is not passing q when defined in solrconfig.xml
[
https://issues.apache.org/jira/browse/SOLR-5138?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737117#comment-13737117
]
Hoss Man commented on SOLR-5138:
1) the example requestHandler config you declared isn't valid XML.
2) with teh following solrconfig.xml, i get the exact same behavior in Solr
3.6.2 as i get in from the head of hte 4x branch...
http://localhost:8983/solr/select?echoParams=allqt=providerdetailsrows=0
{code}
?xml version=1.0 encoding=UTF-8 ?
config
luceneMatchVersionLUCENE_36/luceneMatchVersion
requestDispatcher handleSelect=true
requestParsers enableRemoteStreaming=true
multipartUploadLimitInKB=2048000 /
/requestDispatcher
requestHandler name=providerdetails class=solr.SearchHandler
lst name=defaults
str name=q*:*/str
str name=defTypelucene/str
str name=echoParamsnone/str
str name=wtjson/str
/lst
/requestHandler
/config
{code}
http://localhost:8983/solr/select?echoParams=allqt=providerdetailsrows=0
{code}
{responseHeader:{status:0,QTime:1,params:{echoParams:all,q:*:*,wt:json,defType:lucene,qt:providerdetails,rows:0,echoParams:all}},response:{numFound:21,start:0,docs:[]}}
{code}
...if you are seeing differnet behavior between 3.6 and 4.x wit hteh same
request handler definition, then i suspect you have other descrepencies between
the solrconfig.xml files you are using -- most likeley related to the
handleSelect attribute on request dispatching, and/or you have a
requestHandler named /select defined.
(that's what i would suspect given your description of what you see from 4.x --
if you do in fact have a handler named /select then it, and it's defaults,
will be used to process your request -- and it won't ever even look at your
qt param.)
requestHandler (qt) is not passing q when defined in solrconfig.xml
---
Key: SOLR-5138
URL: https://issues.apache.org/jira/browse/SOLR-5138
Project: Solr
Issue Type: Bug
Affects Versions: 4.5
Environment: OS: Linux 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23
19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux
SOLR: 4.5-SNAPSHOT 1511470M - 2013-08-07 18:30:52
Reporter: Bill Bell
Priority: Critical
We have this qt defined:
requestHandler name=providerdetails class=solr.SearchHandler
lst name=defaults
str name=q*:*/str
str name=defTypelucene/str
str name=echoParamsnone/str
str name=wtjson/str
/requestHandler
When called like this
http://localhost:8080/solr/provider/select?echoParams=ALLfq=pwid:xlkm7wt=xmlqt=providerdetails
the q does not seem to be recognized and no results are returned unless the
q is explicitly set. In SOLR 3.6 the q is seen by the request handler.
SOLR 4.5 (4.5-SNAPSHOT 1511470M - 2013-08-07 18:30:52) returns this - note
that q=*:* is missing:
responselst name=responseHeaderint name=status0/intint
name=QTime1/intlst name=paramsstr name=echoParamsALL/strstr
name=echoParamsALL/strstr name=qtproviderdetails/strstr
name=wtxml/strstr name=fqpwid:xlkm7/str/lst/lstresult
name=response numFound=0 start=0//response
3.6.2 returns the following - note q=*:* is shown:
lst name=responseHeaderint name=status0/intint
name=QTime1/intlst name=paramsstr name=echoParamsALL/strstr
name=q*:*/strstr name=wtxml/strstr
name=echoParamsALL/strstr name=wtxml/strstr
name=qtproviderdetails/strstr name=fqpwid:xlkm7/str/lst/lst
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5138) requestHandler (qt) is not passing q when defined in solrconfig.xml
[ https://issues.apache.org/jira/browse/SOLR-5138?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-5138. Resolution: Cannot Reproduce If my comment doesn't help shed ligght on the descrepency you are seeing, please re-open after attaching a complete set of configs such that when putting those cofigs in /tmp/somedirname and running java -Dsolr.solr.home=/tmp/somedirname -jar start.jar you get different results depending on wether you use Solr 3.6.x or Solr 4.x. requestHandler (qt) is not passing q when defined in solrconfig.xml --- Key: SOLR-5138 URL: https://issues.apache.org/jira/browse/SOLR-5138 Project: Solr Issue Type: Bug Affects Versions: 4.5 Environment: OS: Linux 2.6.32-358.6.1.el6.x86_64 #1 SMP Tue Apr 23 19:29:00 UTC 2013 x86_64 x86_64 x86_64 GNU/Linux SOLR: 4.5-SNAPSHOT 1511470M - 2013-08-07 18:30:52 Reporter: Bill Bell Priority: Critical We have this qt defined: requestHandler name=providerdetails class=solr.SearchHandler lst name=defaults str name=q*:*/str str name=defTypelucene/str str name=echoParamsnone/str str name=wtjson/str /requestHandler When called like this http://localhost:8080/solr/provider/select?echoParams=ALLfq=pwid:xlkm7wt=xmlqt=providerdetails the q does not seem to be recognized and no results are returned unless the q is explicitly set. In SOLR 3.6 the q is seen by the request handler. SOLR 4.5 (4.5-SNAPSHOT 1511470M - 2013-08-07 18:30:52) returns this - note that q=*:* is missing: responselst name=responseHeaderint name=status0/intint name=QTime1/intlst name=paramsstr name=echoParamsALL/strstr name=echoParamsALL/strstr name=qtproviderdetails/strstr name=wtxml/strstr name=fqpwid:xlkm7/str/lst/lstresult name=response numFound=0 start=0//response 3.6.2 returns the following - note q=*:* is shown: lst name=responseHeaderint name=status0/intint name=QTime1/intlst name=paramsstr name=echoParamsALL/strstr name=q*:*/strstr name=wtxml/strstr name=echoParamsALL/strstr name=wtxml/strstr name=qtproviderdetails/strstr name=fqpwid:xlkm7/str/lst/lst -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5162) TestBlockJoinSorting.testNestedSorting asset fails
[
https://issues.apache.org/jira/browse/LUCENE-5162?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737144#comment-13737144
]
Mikhail Khludnev commented on LUCENE-5162:
--
Thanks Martin,
I'm leaving rev reference in case anybody need it
http://svn.apache.org/viewvc/lucene/dev/branches/lucene_solr_4_3/lucene/join/src/test/org/apache/lucene/search/join/TestBlockJoinSorting.java?r1=1513103r2=1513102pathrev=1513103
TestBlockJoinSorting.testNestedSorting asset fails
---
Key: LUCENE-5162
URL: https://issues.apache.org/jira/browse/LUCENE-5162
Project: Lucene - Core
Issue Type: Bug
Components: core/other
Affects Versions: 4.3.1
Reporter: Mikhail Khludnev
Assignee: Martijn van Groningen
Priority: Minor
ant test -Dtestcase=TestBlockJoinSorting -Dtests.method=testNestedSorting
-Dtests.seed=FB4F1BE85579255B -Dtests.slow=true -Dtests.locale=da_DK
-Dtests.timezone=Asia/Qatar -Dtests.file.encoding=UTF-8
[junit4:junit4] FAILURE 0.86s | TestBlockJoinSorting.testNestedSorting
[junit4:junit4] Throwable #1: java.lang.AssertionError: expected:3 but
was:28
[junit4:junit4] at
__randomizedtesting.SeedInfo.seed([FB4F1BE85579255B:F3A6F6A915D02835]:0)
[junit4:junit4] at
org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting(TestBlockJoinSorting.java:226)
[junit4:junit4] at java.lang.Thread.run(Thread.java:680)
[junit4:junit4] 2 NOTE: test params are: codec=Asserting,
sim=RandomSimilarityProvider(queryNorm=true,coord=crazy): {}, locale=da_DK,
timezone=Asia/Qatar
[junit4:junit4]
[junit4:junit4] Tests with failures:
[junit4:junit4] -
org.apache.lucene.search.join.TestBlockJoinSorting.testNestedSorting
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5092) join: don't expect all filters to be FixedBitSet instances
[ https://issues.apache.org/jira/browse/LUCENE-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737188#comment-13737188 ] Yonik Seeley commented on LUCENE-5092: -- bq. I think it's best if we continue to require a FBS so users get a clear exception instead of silent performance hit. That seems reasonable. What about at least changing it from a concrete implementation to Bits though? join: don't expect all filters to be FixedBitSet instances -- Key: LUCENE-5092 URL: https://issues.apache.org/jira/browse/LUCENE-5092 Project: Lucene - Core Issue Type: Improvement Components: modules/join Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-5092.patch The join module throws exceptions when the parents filter isn't a FixedBitSet. The reason is that the join module relies on prevSetBit to find the first child document given a parent ID. As suggested by Uwe and Paul Elschot on LUCENE-5081, we could fix it by exposing methods in the iterators to iterate backwards. When the join modules gets an iterator which isn't able to iterate backwards, it would just need to dump its content into another DocIdSet that supports backward iteration, FixedBitSet for example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5139) Make Core Admin more user friendly when in SolrCloud mode.
Mark Miller created SOLR-5139: - Summary: Make Core Admin more user friendly when in SolrCloud mode. Key: SOLR-5139 URL: https://issues.apache.org/jira/browse/SOLR-5139 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Fix For: 4.5, 5.0 The CoreAdmin in the UI can easily get users into trouble - especially since we don't yet have a collection management API. The info displayed is useful though, and sometimes it makes sense to have access to the commands on a per core level as well. We should improve the situation though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5139) Make Core Admin more user friendly when in SolrCloud mode.
[ https://issues.apache.org/jira/browse/SOLR-5139?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737242#comment-13737242 ] Mark Miller commented on SOLR-5139: --- A couple ideas: 1. Detect SolrCloud mode and display some text warning about using the core admin commands in solrcloud mode. 2. Disable all the controls in SolrCloud mode unless you unlock them with an 'expert' control. Other ideas? Make Core Admin more user friendly when in SolrCloud mode. -- Key: SOLR-5139 URL: https://issues.apache.org/jira/browse/SOLR-5139 Project: Solr Issue Type: Improvement Components: SolrCloud Reporter: Mark Miller Fix For: 4.5, 5.0 The CoreAdmin in the UI can easily get users into trouble - especially since we don't yet have a collection management API. The info displayed is useful though, and sometimes it makes sense to have access to the commands on a per core level as well. We should improve the situation though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4583) StraightBytesDocValuesField fails if bytes 32k
[
https://issues.apache.org/jira/browse/LUCENE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737260#comment-13737260
]
Yonik Seeley commented on LUCENE-4583:
--
I'm confused by the following comment:
{code}
+ /** Maximum length for each binary doc values field,
+ * because we use PagedBytes with page size of 16 bits. */
+ public static final int MAX_BINARY_FIELD_LENGTH = (1 16) + 1;
{code}
But this patch removes the PagedBytes limitation, right?
After this patch, are there any remaining code limitations that prevent raising
the limit, or is it really just self imposed via
{code}
+ if (v.length Lucene42DocValuesFormat.MAX_BINARY_FIELD_LENGTH) {
+throw new IllegalArgumentException(DocValuesField \ + field.name +
\ is too large, must be = +
Lucene42DocValuesFormat.MAX_BINARY_FIELD_LENGTH);
+ }
{code}
StraightBytesDocValuesField fails if bytes 32k
Key: LUCENE-4583
URL: https://issues.apache.org/jira/browse/LUCENE-4583
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 4.0, 4.1, 5.0
Reporter: David Smiley
Assignee: Michael McCandless
Priority: Critical
Fix For: 5.0, 4.5
Attachments: LUCENE-4583.patch, LUCENE-4583.patch, LUCENE-4583.patch,
LUCENE-4583.patch, LUCENE-4583.patch, LUCENE-4583.patch, LUCENE-4583.patch
I didn't observe any limitations on the size of a bytes based DocValues field
value in the docs. It appears that the limit is 32k, although I didn't get
any friendly error telling me that was the limit. 32k is kind of small IMO;
I suspect this limit is unintended and as such is a bug.The following
test fails:
{code:java}
public void testBigDocValue() throws IOException {
Directory dir = newDirectory();
IndexWriter writer = new IndexWriter(dir, writerConfig(false));
Document doc = new Document();
BytesRef bytes = new BytesRef((4+4)*4097);//4096 works
bytes.length = bytes.bytes.length;//byte data doesn't matter
doc.add(new StraightBytesDocValuesField(dvField, bytes));
writer.addDocument(doc);
writer.commit();
writer.close();
DirectoryReader reader = DirectoryReader.open(dir);
DocValues docValues = MultiDocValues.getDocValues(reader, dvField);
//FAILS IF BYTES IS BIG!
docValues.getSource().getBytes(0, bytes);
reader.close();
dir.close();
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir resolved LUCENE-5166. - Resolution: Fixed Fix Version/s: 4.5 5.0 Thank you Manuel! PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Fix For: 5.0, 4.5 Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5166) PostingsHighlighter fails with IndexOutOfBoundsException
[ https://issues.apache.org/jira/browse/LUCENE-5166?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737270#comment-13737270 ] ASF subversion and git services commented on LUCENE-5166: - Commit 1513231 from [~rcmuir] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1513231 ] LUCENE-5166: PostingsHighlighter fails with IndexOutOfBoundsException PostingsHighlighter fails with IndexOutOfBoundsException Key: LUCENE-5166 URL: https://issues.apache.org/jira/browse/LUCENE-5166 Project: Lucene - Core Issue Type: Bug Components: modules/highlighter Affects Versions: 4.4 Reporter: Manuel Amoabeng Attachments: LUCENE-5166-2.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch, LUCENE-5166.patch Given a document with a match at a startIndex PostingsHighlighter.maxlength and an endIndex PostingsHighlighter.maxLength, DefaultPassageFormatter will throw an IndexOutOfBoundsException when DefaultPassageFormatter.append() is invoked. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5119) Managed schema problems after adding fields via Schema Rest API
[
https://issues.apache.org/jira/browse/SOLR-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737272#comment-13737272
]
Steve Rowe commented on SOLR-5119:
--
I was able to reproduce both problems, in standalone mode and in SolrCloud mode.
Steps to reproduce in standalone mode: start the example in managed schema
mode; add one or more fields via the REST API (e.g. the {{curl}} add fields
command given in the description), then either reload the core or view the
schema from the admin UI.
The source of both problems is the same: {{ManagedIndexSchema.shallowCopy()}}
doesn't set {{resourceName}} at all, and then when it's referenced an NPE
occurs:
{noformat}
382354 [qtp1973711593-30] INFO org.apache.solr.servlet.SolrDispatchFilter –
[admin] webapp=null path=/admin/cores
params={action=RELOAD_=1376332774482core=collection1wt=json} status=500
QTime=195
382355 [qtp1973711593-30] ERROR org.apache.solr.servlet.SolrDispatchFilter –
null:org.apache.solr.common.SolrException: Error handling 'reload' action
at
org.apache.solr.handler.admin.CoreAdminHandler.handleReloadAction(CoreAdminHandler.java:671)
at
org.apache.solr.handler.admin.CoreAdminHandler.handleRequestBody(CoreAdminHandler.java:172)
at
org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135)
at
org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest(SolrDispatchFilter.java:618)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:209)
at
org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:158)
at
org.eclipse.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1419)
at
org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:455)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:137)
at
org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:557)
at
org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:231)
at
org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1075)
at
org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:384)
at
org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:193)
at
org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1009)
at
org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:135)
at
org.eclipse.jetty.server.handler.ContextHandlerCollection.handle(ContextHandlerCollection.java:255)
at
org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:154)
at
org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:116)
at org.eclipse.jetty.server.Server.handle(Server.java:368)
at
org.eclipse.jetty.server.AbstractHttpConnection.handleRequest(AbstractHttpConnection.java:489)
at
org.eclipse.jetty.server.BlockingHttpConnection.handleRequest(BlockingHttpConnection.java:53)
at
org.eclipse.jetty.server.AbstractHttpConnection.headerComplete(AbstractHttpConnection.java:942)
at
org.eclipse.jetty.server.AbstractHttpConnection$RequestHandler.headerComplete(AbstractHttpConnection.java:1004)
at org.eclipse.jetty.http.HttpParser.parseNext(HttpParser.java:640)
at org.eclipse.jetty.http.HttpParser.parseAvailable(HttpParser.java:235)
at
org.eclipse.jetty.server.BlockingHttpConnection.handle(BlockingHttpConnection.java:72)
at
org.eclipse.jetty.server.bio.SocketConnector$ConnectorEndPoint.run(SocketConnector.java:264)
at
org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:608)
at
org.eclipse.jetty.util.thread.QueuedThreadPool$3.run(QueuedThreadPool.java:543)
at java.lang.Thread.run(Thread.java:724)
Caused by: org.apache.solr.common.SolrException: Unable to reload core:
collection1
at
org.apache.solr.core.CoreContainer.recordAndThrow(CoreContainer.java:930)
at org.apache.solr.core.CoreContainer.reload(CoreContainer.java:685)
at
org.apache.solr.handler.admin.CoreAdminHandler.handleReloadAction(CoreAdminHandler.java:669)
... 30 more
Caused by: java.lang.NullPointerException
at
org.apache.solr.schema.ManagedIndexSchemaFactory.warnIfNonManagedSchemaExists(ManagedIndexSchemaFactory.java:222)
at
org.apache.solr.schema.ManagedIndexSchemaFactory.readSchemaLocally(ManagedIndexSchemaFactory.java:197)
at
org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:118)
at
org.apache.solr.schema.ManagedIndexSchemaFactory.create(ManagedIndexSchemaFactory.java:45)
at
org.apache.solr.schema.IndexSchemaFactory.buildIndexSchema(IndexSchemaFactory.java:69)
[jira] [Updated] (SOLR-5119) Managed schema problems after adding fields via Schema Rest API
[
https://issues.apache.org/jira/browse/SOLR-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-5119:
-
Attachment: SOLR-5119.patch
Trivial patch, makes {{ManagedIndexSchema.shallowCopy()}} set {{resourceName}}
to {{managedSchemaResourceName}}; also adds a test that reloads the core after
adding a field in managed schema mode, which fails before the patch and
succeeds after.
Committing shortly.
Managed schema problems after adding fields via Schema Rest API
Key: SOLR-5119
URL: https://issues.apache.org/jira/browse/SOLR-5119
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.4
Reporter: NilsK
Assignee: Steve Rowe
Priority: Critical
Attachments: SOLR-5119.patch
After adding fields with the Schema API the schema cannot be shown on the
Admin UI anymore and reloading the Collection/Core throws an
NullPointerException. The schema itself seems to work.
Steps to reproduce:
1. enable managed schema in example/solr/collection1/conf/solrconfig.xml
2. upload that config
{code}sh example/cloud-scripts/zkcli.sh -z localhost:8575 -cmd upconfig -d
example/solr/collection1/conf/ -n myconfig{code}
3. create a new collection
{code}curl
http://localhost:8983/solr/admin/collections?action=CREATEname=mycollectionnumShards=1replicationFactor=1collection.configName=myconfig{code}
4. add some fields
{code}curl http://localhost:8983/solr/mycollection/schema/fields -X POST -H
'Content-type:application/json' --data-binary '[
{
  name: my_field,
  type: string,
  stored: true,
  indexed: true
},
{
  name: my_field2,
  type: string,
  stored: true,
  indexed: true
}
]'{code}
5. *Problem 1*:
http://localhost:8983/solr/#/mycollection_shard1_replica1/schema
{code}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status404/intint
name=QTime2/int/lstlst name=errorstr name=msgCan not find:
/configs/myconfig/null/strint name=code404/int/lst
/response
{code}
6. *Problem 2*:
http://localhost:8983/solr/admin/collections?action=RELOADname=mycollection
{code}
response
lst name=responseHeaderint name=status0/intint
name=QTime845/int/lstlst name=failurestr
name=10.147.252.2:8983_solrorg.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Server
at http://10.147.252.2:8983/solr returned non ok status:500, message:Server
Error/str/lst
/response
{code}
7. when restarting Solr, both 5 and 6 work
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 725 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/725/ Java: 64bit/jdk1.7.0 -XX:+UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 9838 lines...] [junit4] ERROR: JVM J0 ended with an exception, command line: /Library/Java/JavaVirtualMachines/jdk1.7.0_25.jdk/Contents/Home/jre/bin/java -XX:+UseCompressedOops -XX:+UseG1GC -XX:+HeapDumpOnOutOfMemoryError -XX:HeapDumpPath=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/heapdumps -Dtests.prefix=tests -Dtests.seed=A3038272298A20AA -Xmx512M -Dtests.iters= -Dtests.verbose=false -Dtests.infostream=false -Dtests.codec=random -Dtests.postingsformat=random -Dtests.docvaluesformat=random -Dtests.locale=random -Dtests.timezone=random -Dtests.directory=random -Dtests.linedocsfile=europarl.lines.txt.gz -Dtests.luceneMatchVersion=5.0 -Dtests.cleanthreads=perClass -Djava.util.logging.config.file=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/logging.properties -Dtests.nightly=false -Dtests.weekly=false -Dtests.slow=true -Dtests.asserts.gracious=false -Dtests.multiplier=1 -DtempDir=. -Djava.io.tmpdir=. -Djunit4.tempDir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/build/solr-core/test/temp -Dclover.db.dir=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/clover/db -Djava.security.manager=org.apache.lucene.util.TestSecurityManager -Djava.security.policy=/Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/tools/junit4/tests.policy -Dlucene.version=5.0-SNAPSHOT -Djetty.testMode=1 -Djetty.insecurerandom=1 -Dsolr.directoryFactory=org.apache.solr.core.MockDirectoryFactory -Djava.awt.headless=true -Dtests.disableHdfs=true -Dfile.encoding=ISO-8859-1 -classpath
Re: [JENKINS] Lucene-Solr-4.x-Linux (32bit/jdk1.7.0_25) - Build # 6874 - Failure!
I can now reproduce this, but in a crazy way. (I reproduced it twice, and first time it failed in FastVectorHighlighter, second time in PostingsHighlighter!) So i think this really looks like a JVM bug (i have not tried other possibilties or combinations, i will open an issue). REPRO #1: rmuir@beast:~/workspace/branch_4x$ svn up -r 1512807 rmuir@beast:~/workspace/branch_4x$ ant clean rmuir@beast:~/workspace/branch_4x$ rm -rf .caches #this is important, otherwise master seed does not work! rmuir@beast:~/workspace/branch_4x/lucene/highlighter$ ant test -Dtests.jvms=2 -Dtests.seed=EBBFA6F4E80A7365 -Dargs=-server -XX:+UseG1GC [junit4] Suite: org.apache.lucene.search.vectorhighlight.FastVectorHighlighterTest [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=FastVectorHighlighterTest -Dtests.method=testCommonTermsQueryHighlightTest -Dtests.seed=EBBFA6F4E80A7365 -Dtests.slow=true -Dtests.locale=es_PA -Dtests.timezone=America/Indiana/Vincennes -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.02s J1 | FastVectorHighlighterTest.testCommonTermsQueryHighlightTest [junit4] Throwable #1: java.lang.AssertionError [junit4]at __randomizedtesting.SeedInfo.seed([EBBFA6F4E80A7365:D307BBE9A713DA33]:0) [junit4]at org.apache.lucene.index.ByteSliceReader.readByte(ByteSliceReader.java:73) [junit4]at org.apache.lucene.store.DataInput.readVInt(DataInput.java:108) [junit4]at org.apache.lucene.index.FreqProxTermsWriterPerField.flush(FreqProxTermsWriterPerField.java:453) [junit4]at org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:85) [junit4]at org.apache.lucene.index.TermsHash.flush(TermsHash.java:116) [junit4]at org.apache.lucene.index.DocInverter.flush(DocInverter.java:53) [junit4]at org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:81) [junit4]at org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:501) [junit4]at org.apache.lucene.index.DocumentsWriter.doFlush(DocumentsWriter.java:478) [junit4]at org.apache.lucene.index.DocumentsWriter.flushAllThreads(DocumentsWriter.java:615) [junit4]at org.apache.lucene.index.IndexWriter.getReader(IndexWriter.java:365) [junit4]at org.apache.lucene.index.DirectoryReader.open(DirectoryReader.java:111) [junit4]at org.apache.lucene.search.vectorhighlight.FastVectorHighlighterTest.testCommonTermsQueryHighlightTest(FastVectorHighlighterTest.java:285) [junit4]at java.lang.Thread.run(Thread.java:724) [junit4] 2 NOTE: test params are: codec=Lucene3x, sim=DefaultSimilarity, locale=es_PA, timezone=America/Indiana/Vincennes [junit4] 2 NOTE: Linux 3.5.0-27-generic i386/Oracle Corporation 1.7.0_25 (32-bit)/cpus=8,threads=1,free=48330984,total=67108864 [junit4] 2 NOTE: All tests run in this JVM: [WeightedFragListBuilderTest, IndexTimeSynonymTest, ScoreOrderFragmentsBuilderTest, HighlighterTest, FieldPhraseListTest, HighlighterPhraseTest, SimpleFragListBuilderTest, FieldTermStackTest, SimpleFragmentsBuilderTest, FieldQueryTest, TestPostingsHighlighter, FastVectorHighlighterTest] [junit4] Completed on J1 in 0.16s, 6 tests, 1 failure FAILURES! REPRO #2: rmuir@beast:~/workspace/branch_4x$ rm -rf .caches #this is important, otherwise master seed does not work! rmuir@beast:~/workspace/branch_4x/lucene/highlighter$ ant test -Dtests.jvms=2 -Dtests.seed=EBBFA6F4E80A7365 -Dargs=-server -XX:+UseG1GC [junit4] Suite: org.apache.lucene.search.postingshighlight.TestPostingsHighlighter [junit4] 2 NOTE: reproduce with: ant test -Dtestcase=TestPostingsHighlighter -Dtests.method=testUserFailedToIndexOffsets -Dtests.seed=EBBFA6F4E80A7365 -Dtests.slow=true -Dtests.locale=lt_LT -Dtests.timezone=Europe/Isle_of_Man -Dtests.file.encoding=UTF-8 [junit4] FAILURE 0.02s J1 | TestPostingsHighlighter.testUserFailedToIndexOffsets [junit4] Throwable #1: java.lang.AssertionError [junit4]at __randomizedtesting.SeedInfo.seed([EBBFA6F4E80A7365:1FBF811885F2D611]:0) [junit4]at org.apache.lucene.index.ByteSliceReader.readByte(ByteSliceReader.java:73) [junit4]at org.apache.lucene.store.DataInput.readVInt(DataInput.java:108) [junit4]at org.apache.lucene.index.FreqProxTermsWriterPerField.flush(FreqProxTermsWriterPerField.java:453) [junit4]at org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:85) [junit4]at org.apache.lucene.index.TermsHash.flush(TermsHash.java:116) [junit4]at org.apache.lucene.index.DocInverter.flush(DocInverter.java:53) [junit4]at org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:81) [junit4]at org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:501)
[jira] [Commented] (SOLR-5119) Managed schema problems after adding fields via Schema Rest API
[
https://issues.apache.org/jira/browse/SOLR-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737299#comment-13737299
]
ASF subversion and git services commented on SOLR-5119:
---
Commit 1513238 from [~steve_rowe] in branch 'dev/trunk'
[ https://svn.apache.org/r1513238 ]
SOLR-5119: Managed schema problems after adding fields via Schema Rest API
Managed schema problems after adding fields via Schema Rest API
Key: SOLR-5119
URL: https://issues.apache.org/jira/browse/SOLR-5119
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.4
Reporter: NilsK
Assignee: Steve Rowe
Priority: Critical
Attachments: SOLR-5119.patch
After adding fields with the Schema API the schema cannot be shown on the
Admin UI anymore and reloading the Collection/Core throws an
NullPointerException. The schema itself seems to work.
Steps to reproduce:
1. enable managed schema in example/solr/collection1/conf/solrconfig.xml
2. upload that config
{code}sh example/cloud-scripts/zkcli.sh -z localhost:8575 -cmd upconfig -d
example/solr/collection1/conf/ -n myconfig{code}
3. create a new collection
{code}curl
http://localhost:8983/solr/admin/collections?action=CREATEname=mycollectionnumShards=1replicationFactor=1collection.configName=myconfig{code}
4. add some fields
{code}curl http://localhost:8983/solr/mycollection/schema/fields -X POST -H
'Content-type:application/json' --data-binary '[
{
  name: my_field,
  type: string,
  stored: true,
  indexed: true
},
{
  name: my_field2,
  type: string,
  stored: true,
  indexed: true
}
]'{code}
5. *Problem 1*:
http://localhost:8983/solr/#/mycollection_shard1_replica1/schema
{code}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status404/intint
name=QTime2/int/lstlst name=errorstr name=msgCan not find:
/configs/myconfig/null/strint name=code404/int/lst
/response
{code}
6. *Problem 2*:
http://localhost:8983/solr/admin/collections?action=RELOADname=mycollection
{code}
response
lst name=responseHeaderint name=status0/intint
name=QTime845/int/lstlst name=failurestr
name=10.147.252.2:8983_solrorg.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Server
at http://10.147.252.2:8983/solr returned non ok status:500, message:Server
Error/str/lst
/response
{code}
7. when restarting Solr, both 5 and 6 work
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5119) Managed schema problems after adding fields via Schema Rest API
[
https://issues.apache.org/jira/browse/SOLR-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737301#comment-13737301
]
ASF subversion and git services commented on SOLR-5119:
---
Commit 1513240 from [~steve_rowe] in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1513240 ]
SOLR-5119: Managed schema problems after adding fields via Schema Rest API
(merged trunk r1513238)
Managed schema problems after adding fields via Schema Rest API
Key: SOLR-5119
URL: https://issues.apache.org/jira/browse/SOLR-5119
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.4
Reporter: NilsK
Assignee: Steve Rowe
Priority: Critical
Attachments: SOLR-5119.patch
After adding fields with the Schema API the schema cannot be shown on the
Admin UI anymore and reloading the Collection/Core throws an
NullPointerException. The schema itself seems to work.
Steps to reproduce:
1. enable managed schema in example/solr/collection1/conf/solrconfig.xml
2. upload that config
{code}sh example/cloud-scripts/zkcli.sh -z localhost:8575 -cmd upconfig -d
example/solr/collection1/conf/ -n myconfig{code}
3. create a new collection
{code}curl
http://localhost:8983/solr/admin/collections?action=CREATEname=mycollectionnumShards=1replicationFactor=1collection.configName=myconfig{code}
4. add some fields
{code}curl http://localhost:8983/solr/mycollection/schema/fields -X POST -H
'Content-type:application/json' --data-binary '[
{
  name: my_field,
  type: string,
  stored: true,
  indexed: true
},
{
  name: my_field2,
  type: string,
  stored: true,
  indexed: true
}
]'{code}
5. *Problem 1*:
http://localhost:8983/solr/#/mycollection_shard1_replica1/schema
{code}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status404/intint
name=QTime2/int/lstlst name=errorstr name=msgCan not find:
/configs/myconfig/null/strint name=code404/int/lst
/response
{code}
6. *Problem 2*:
http://localhost:8983/solr/admin/collections?action=RELOADname=mycollection
{code}
response
lst name=responseHeaderint name=status0/intint
name=QTime845/int/lstlst name=failurestr
name=10.147.252.2:8983_solrorg.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Server
at http://10.147.252.2:8983/solr returned non ok status:500, message:Server
Error/str/lst
/response
{code}
7. when restarting Solr, both 5 and 6 work
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5119) Managed schema problems after adding fields via Schema Rest API
[
https://issues.apache.org/jira/browse/SOLR-5119?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe resolved SOLR-5119.
--
Resolution: Fixed
Fix Version/s: 5.0
4.5
Committed to trunk and branch_4x.
Thanks Nils!
Managed schema problems after adding fields via Schema Rest API
Key: SOLR-5119
URL: https://issues.apache.org/jira/browse/SOLR-5119
Project: Solr
Issue Type: Bug
Components: Schema and Analysis
Affects Versions: 4.4
Reporter: NilsK
Assignee: Steve Rowe
Priority: Critical
Fix For: 4.5, 5.0
Attachments: SOLR-5119.patch
After adding fields with the Schema API the schema cannot be shown on the
Admin UI anymore and reloading the Collection/Core throws an
NullPointerException. The schema itself seems to work.
Steps to reproduce:
1. enable managed schema in example/solr/collection1/conf/solrconfig.xml
2. upload that config
{code}sh example/cloud-scripts/zkcli.sh -z localhost:8575 -cmd upconfig -d
example/solr/collection1/conf/ -n myconfig{code}
3. create a new collection
{code}curl
http://localhost:8983/solr/admin/collections?action=CREATEname=mycollectionnumShards=1replicationFactor=1collection.configName=myconfig{code}
4. add some fields
{code}curl http://localhost:8983/solr/mycollection/schema/fields -X POST -H
'Content-type:application/json' --data-binary '[
{
  name: my_field,
  type: string,
  stored: true,
  indexed: true
},
{
  name: my_field2,
  type: string,
  stored: true,
  indexed: true
}
]'{code}
5. *Problem 1*:
http://localhost:8983/solr/#/mycollection_shard1_replica1/schema
{code}
?xml version=1.0 encoding=UTF-8?
response
lst name=responseHeaderint name=status404/intint
name=QTime2/int/lstlst name=errorstr name=msgCan not find:
/configs/myconfig/null/strint name=code404/int/lst
/response
{code}
6. *Problem 2*:
http://localhost:8983/solr/admin/collections?action=RELOADname=mycollection
{code}
response
lst name=responseHeaderint name=status0/intint
name=QTime845/int/lstlst name=failurestr
name=10.147.252.2:8983_solrorg.apache.solr.client.solrj.impl.HttpSolrServer$RemoteSolrException:Server
at http://10.147.252.2:8983/solr returned non ok status:500, message:Server
Error/str/lst
/response
{code}
7. when restarting Solr, both 5 and 6 work
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (LUCENE-5168) ByteSliceReader assert trips with 32-bit oracle 1.7.0_25 + G1GC
Robert Muir created LUCENE-5168:
---
Summary: ByteSliceReader assert trips with 32-bit oracle 1.7.0_25
+ G1GC
Key: LUCENE-5168
URL: https://issues.apache.org/jira/browse/LUCENE-5168
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
This assertion trips (sometimes from different tests), if you run the
highlighting tests on branch_4x with r1512807.
It reproduces about half the time, always only with 32bit + G1GC (other
combinations do not seem to trip it, i didnt try looping or anything really
though).
{noformat}
rmuir@beast:~/workspace/branch_4x$ svn up -r 1512807
rmuir@beast:~/workspace/branch_4x$ ant clean
rmuir@beast:~/workspace/branch_4x$ rm -rf .caches #this is important,
otherwise master seed does not work!
rmuir@beast:~/workspace/branch_4x/lucene/highlighter$ ant test
-Dtests.jvms=2 -Dtests.seed=EBBFA6F4E80A7365 -Dargs=-server
-XX:+UseG1GC
{noformat}
Originally showed up like this:
{noformat}
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/6874/
Java: 32bit/jdk1.7.0_25 -server -XX:+UseG1GC
1 tests failed.
REGRESSION:
org.apache.lucene.search.postingshighlight.TestPostingsHighlighter.testUserFailedToIndexOffsets
Error Message:
Stack Trace:
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([EBBFA6F4E80A7365:1FBF811885F2D611]:0)
at
org.apache.lucene.index.ByteSliceReader.readByte(ByteSliceReader.java:73)
at org.apache.lucene.store.DataInput.readVInt(DataInput.java:108)
at
org.apache.lucene.index.FreqProxTermsWriterPerField.flush(FreqProxTermsWriterPerField.java:453)
at
org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:85)
at org.apache.lucene.index.TermsHash.flush(TermsHash.java:116)
at org.apache.lucene.index.DocInverter.flush(DocInverter.java:53)
at
org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:81)
at
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:501)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5168) ByteSliceReader assert trips with 32-bit oracle 1.7.0_25 + G1GC
[
https://issues.apache.org/jira/browse/LUCENE-5168?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737314#comment-13737314
]
Robert Muir commented on LUCENE-5168:
-
I also cannot make this fail if I add -Xint or -Xbatch
ByteSliceReader assert trips with 32-bit oracle 1.7.0_25 + G1GC
---
Key: LUCENE-5168
URL: https://issues.apache.org/jira/browse/LUCENE-5168
Project: Lucene - Core
Issue Type: Bug
Reporter: Robert Muir
This assertion trips (sometimes from different tests), if you run the
highlighting tests on branch_4x with r1512807.
It reproduces about half the time, always only with 32bit + G1GC (other
combinations do not seem to trip it, i didnt try looping or anything really
though).
{noformat}
rmuir@beast:~/workspace/branch_4x$ svn up -r 1512807
rmuir@beast:~/workspace/branch_4x$ ant clean
rmuir@beast:~/workspace/branch_4x$ rm -rf .caches #this is important,
otherwise master seed does not work!
rmuir@beast:~/workspace/branch_4x/lucene/highlighter$ ant test
-Dtests.jvms=2 -Dtests.seed=EBBFA6F4E80A7365 -Dargs=-server
-XX:+UseG1GC
{noformat}
Originally showed up like this:
{noformat}
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/6874/
Java: 32bit/jdk1.7.0_25 -server -XX:+UseG1GC
1 tests failed.
REGRESSION:
org.apache.lucene.search.postingshighlight.TestPostingsHighlighter.testUserFailedToIndexOffsets
Error Message:
Stack Trace:
java.lang.AssertionError
at
__randomizedtesting.SeedInfo.seed([EBBFA6F4E80A7365:1FBF811885F2D611]:0)
at
org.apache.lucene.index.ByteSliceReader.readByte(ByteSliceReader.java:73)
at org.apache.lucene.store.DataInput.readVInt(DataInput.java:108)
at
org.apache.lucene.index.FreqProxTermsWriterPerField.flush(FreqProxTermsWriterPerField.java:453)
at
org.apache.lucene.index.FreqProxTermsWriter.flush(FreqProxTermsWriter.java:85)
at org.apache.lucene.index.TermsHash.flush(TermsHash.java:116)
at org.apache.lucene.index.DocInverter.flush(DocInverter.java:53)
at
org.apache.lucene.index.DocFieldProcessor.flush(DocFieldProcessor.java:81)
at
org.apache.lucene.index.DocumentsWriterPerThread.flush(DocumentsWriterPerThread.java:501)
{noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737315#comment-13737315 ] Grant Ingersoll commented on SOLR-3076: --- Uwe, sounds good. Can you link the new issues here so that we can track them as part of this? Solr(Cloud) should support block joins -- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 4.5, 5.0 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-5092) join: don't expect all filters to be FixedBitSet instances
[ https://issues.apache.org/jira/browse/LUCENE-5092?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737357#comment-13737357 ] Mikhail Khludnev commented on LUCENE-5092: -- bq. or add additional metadata to the documents in the block so we make it easier to go from childs to parent and vice versa. [~thetaphi] (I don't know how but) we can write single byte DocValues per child document with delta to their parent (let's limit block size by 0xff), delta to the previous parent for parent documents. WDYT? join: don't expect all filters to be FixedBitSet instances -- Key: LUCENE-5092 URL: https://issues.apache.org/jira/browse/LUCENE-5092 Project: Lucene - Core Issue Type: Improvement Components: modules/join Reporter: Adrien Grand Assignee: Adrien Grand Priority: Minor Attachments: LUCENE-5092.patch The join module throws exceptions when the parents filter isn't a FixedBitSet. The reason is that the join module relies on prevSetBit to find the first child document given a parent ID. As suggested by Uwe and Paul Elschot on LUCENE-5081, we could fix it by exposing methods in the iterators to iterate backwards. When the join modules gets an iterator which isn't able to iterate backwards, it would just need to dump its content into another DocIdSet that supports backward iteration, FixedBitSet for example. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[
https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737385#comment-13737385
]
Mikhail Khludnev commented on SOLR-3076:
[~thetaphi] what is the reason of delaying this functionality, if we can
deliver it now with the following configuration footprint?
{code:xml}
query
cache name=cachingWrapperFilterCache
class=solr.search.LRUCache
/query
queryParser name=parent class=join.BlockJoinParentQParserPlugin
!-- if you omit this BJQ will perform suboptimal,
thought functionally complete,
also it annoyingly warns --
str name=parent-filter-cachecachingWrapperFilterCache/str
/queryParser
{code}
Broken Solr on segments seems crucial to me too.
I suppose that refactoring will take even much time than this modest piece of
functionality. I feel it's really challenging from design perspective e.g. can
CachingWrapperFilter flip between dense and sparse sets already? shouldn't it
use off-heap memory like in LUCENE-5052 rather than pollute the heap? whether
filters behavior is defined in index time or can be requested ad-hoc? etc
Once again, what about going ahead with small configuration footprint, without
diverging join queries.
thanks
Solr(Cloud) should support block joins
--
Key: SOLR-3076
URL: https://issues.apache.org/jira/browse/SOLR-3076
Project: Solr
Issue Type: New Feature
Reporter: Grant Ingersoll
Fix For: 4.5, 5.0
Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png,
bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch,
child-bjqparser.patch, dih-3076.patch, dih-config.xml,
parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at
1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-7036-childDocs-solr-fork-trunk-patched,
solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch,
tochild-bjq-filtered-search-fix.patch
Lucene has the ability to do block joins, we should add it to Solr.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[
https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737454#comment-13737454
]
Robert Muir commented on SOLR-3076:
---
{quote}
Once again, what about going ahead with small configuration footprint, without
diverging join queries.
{quote}
I am +1 to that setup, like the original patches on this issue (especially for
block joins, its typically only ONE filter anyway: and one that must support
some special stuff like prevSetBit or whatever at the moment compared to
general filters). So even long term, maybe a separate cache makes sense because
e.g. you want to use compressed implementations for your 'ordinary' filters.
{quote}
Broken Solr on segments seems crucial to me too.
I suppose that refactoring will take even much time than this modest piece of
functionality.
{quote}
I'm willing to volunteer a significant amount of my time (e.g. like, starting
right now) to make it happen. As it stands now its very difficult for users to
use solr's features if their index is changing rapidly: lots of garbage and
slow reopens. But right or wrong, i always felt restrained from fixing this,
for some of the same reasons Uwe mentions...
Solr(Cloud) should support block joins
--
Key: SOLR-3076
URL: https://issues.apache.org/jira/browse/SOLR-3076
Project: Solr
Issue Type: New Feature
Reporter: Grant Ingersoll
Fix For: 4.5, 5.0
Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png,
bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch,
child-bjqparser.patch, dih-3076.patch, dih-config.xml,
parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at
1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch,
SOLR-7036-childDocs-solr-fork-trunk-patched,
solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch,
tochild-bjq-filtered-search-fix.patch
Lucene has the ability to do block joins, we should add it to Solr.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737468#comment-13737468 ] Yonik Seeley commented on SOLR-3076: bq. I don't think we should again start with bq. Ah, the joy of lucene vs solr politics Heh. And then you proceed to spout a bunch of political b.s. Solr(Cloud) should support block joins -- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 4.5, 5.0 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737472#comment-13737472 ] ASF subversion and git services commented on SOLR-3076: --- Commit 1513290 from [~yo...@apache.org] in branch 'dev/trunk' [ https://svn.apache.org/r1513290 ] SOLR-3076: block join parent and child queries Solr(Cloud) should support block joins -- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 4.5, 5.0 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-3076) Solr(Cloud) should support block joins
[ https://issues.apache.org/jira/browse/SOLR-3076?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737473#comment-13737473 ] Yonik Seeley commented on SOLR-3076: Committed w/ Mikhail's user cache approach. To everyone who contributed to this, thank you for your patience. Solr(Cloud) should support block joins -- Key: SOLR-3076 URL: https://issues.apache.org/jira/browse/SOLR-3076 Project: Solr Issue Type: New Feature Reporter: Grant Ingersoll Fix For: 4.5, 5.0 Attachments: 27M-singlesegment-histogram.png, 27M-singlesegment.png, bjq-vs-filters-backward-disi.patch, bjq-vs-filters-illegal-state.patch, child-bjqparser.patch, dih-3076.patch, dih-config.xml, parent-bjq-qparser.patch, parent-bjq-qparser.patch, Screen Shot 2012-07-17 at 1.12.11 AM.png, SOLR-3076-childDocs.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-3076.patch, SOLR-7036-childDocs-solr-fork-trunk-patched, solrconf-bjq-erschema-snippet.xml, solrconfig.xml.patch, tochild-bjq-filtered-search-fix.patch Lucene has the ability to do block joins, we should add it to Solr. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Created] (SOLR-5140) TestGroupingSearch fails in unreproducible ways
Hoss Man created SOLR-5140: -- Summary: TestGroupingSearch fails in unreproducible ways Key: SOLR-5140 URL: https://issues.apache.org/jira/browse/SOLR-5140 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Hoss Man There have been two very recent jenkins failures in TestGroupingSearch whose failure conditions seem to suggest they may be related to the MergePolicy randomization changes made in SOLR-4952, because they depending on exact ordered comparisons of (grouped) results that are not sorted - so differently merged indexes might produce differnet results... https://mail-archives.apache.org/mod_mbox/lucene-dev/201308.mbox/%3c556758084.41.1376060637739.javamail.jenk...@serv1.sd-datasolutions.de%3E https://mail-archives.apache.org/mod_mbox/lucene-dev/201308.mbox/%3c1729705091.81.1376255711416.javamail.jenk...@serv1.sd-datasolutions.de%3E ...oddly, these failures don't seem to reproduce reliably with the same seed, so rather then just fix the MP as part of SOLR-4952 I'm opening a new linked issue to keep track of this in case additional failures still happen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5140) TestGroupingSearch fails in unreproducible ways
[ https://issues.apache.org/jira/browse/SOLR-5140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737543#comment-13737543 ] ASF subversion and git services commented on SOLR-5140: --- Commit 1513297 from hoss...@apache.org in branch 'dev/trunk' [ https://svn.apache.org/r1513297 ] SOLR-5140: pin TestGroupingSearch to use LogDocMergePolicy for predictable 'unordered' results TestGroupingSearch fails in unreproducible ways --- Key: SOLR-5140 URL: https://issues.apache.org/jira/browse/SOLR-5140 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Hoss Man There have been two very recent jenkins failures in TestGroupingSearch whose failure conditions seem to suggest they may be related to the MergePolicy randomization changes made in SOLR-4952, because they depending on exact ordered comparisons of (grouped) results that are not sorted - so differently merged indexes might produce differnet results... https://mail-archives.apache.org/mod_mbox/lucene-dev/201308.mbox/%3c556758084.41.1376060637739.javamail.jenk...@serv1.sd-datasolutions.de%3E https://mail-archives.apache.org/mod_mbox/lucene-dev/201308.mbox/%3c1729705091.81.1376255711416.javamail.jenk...@serv1.sd-datasolutions.de%3E ...oddly, these failures don't seem to reproduce reliably with the same seed, so rather then just fix the MP as part of SOLR-4952 I'm opening a new linked issue to keep track of this in case additional failures still happen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5140) TestGroupingSearch fails in unreproducible ways
[ https://issues.apache.org/jira/browse/SOLR-5140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737552#comment-13737552 ] ASF subversion and git services commented on SOLR-5140: --- Commit 1513300 from hoss...@apache.org in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1513300 ] SOLR-5140: pin TestGroupingSearch to use LogDocMergePolicy for predictable 'unordered' results (merge r1513297) TestGroupingSearch fails in unreproducible ways --- Key: SOLR-5140 URL: https://issues.apache.org/jira/browse/SOLR-5140 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Hoss Man There have been two very recent jenkins failures in TestGroupingSearch whose failure conditions seem to suggest they may be related to the MergePolicy randomization changes made in SOLR-4952, because they depending on exact ordered comparisons of (grouped) results that are not sorted - so differently merged indexes might produce differnet results... https://mail-archives.apache.org/mod_mbox/lucene-dev/201308.mbox/%3c556758084.41.1376060637739.javamail.jenk...@serv1.sd-datasolutions.de%3E https://mail-archives.apache.org/mod_mbox/lucene-dev/201308.mbox/%3c1729705091.81.1376255711416.javamail.jenk...@serv1.sd-datasolutions.de%3E ...oddly, these failures don't seem to reproduce reliably with the same seed, so rather then just fix the MP as part of SOLR-4952 I'm opening a new linked issue to keep track of this in case additional failures still happen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Resolved] (SOLR-5140) TestGroupingSearch fails in unreproducible ways
[ https://issues.apache.org/jira/browse/SOLR-5140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-5140. Resolution: Fixed i've pinned the test to use LogDocMergePolicy, and am going to assume this has fixed things until/unless we see some new failures. TestGroupingSearch fails in unreproducible ways --- Key: SOLR-5140 URL: https://issues.apache.org/jira/browse/SOLR-5140 Project: Solr Issue Type: Bug Reporter: Hoss Man Assignee: Hoss Man There have been two very recent jenkins failures in TestGroupingSearch whose failure conditions seem to suggest they may be related to the MergePolicy randomization changes made in SOLR-4952, because they depending on exact ordered comparisons of (grouped) results that are not sorted - so differently merged indexes might produce differnet results... https://mail-archives.apache.org/mod_mbox/lucene-dev/201308.mbox/%3c556758084.41.1376060637739.javamail.jenk...@serv1.sd-datasolutions.de%3E https://mail-archives.apache.org/mod_mbox/lucene-dev/201308.mbox/%3c1729705091.81.1376255711416.javamail.jenk...@serv1.sd-datasolutions.de%3E ...oddly, these failures don't seem to reproduce reliably with the same seed, so rather then just fix the MP as part of SOLR-4952 I'm opening a new linked issue to keep track of this in case additional failures still happen -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4905) Cross core joins don't work for SolrCloud collections and/or aliases
[
https://issues.apache.org/jira/browse/SOLR-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737585#comment-13737585
]
Utkarsh Sengar commented on SOLR-4905:
--
@Chris I have solrcloud 4.4 running with 3 shards and 2 cores. A cross-core
join does not work even when cores are created during the bootstrap time.
This is my query:
http://SOLR_SERVER/solr/merchant/select?q={!join from=merchantId to=merchantId
fromIndex=deals}apple
This query returns no documents, full response with debugQuery=true:
http://apaste.info/uHOw
But both of my cores have a common merchantId when I query for apple. So I
think this problem is a general problem in solrcloud.
Cross core joins don't work for SolrCloud collections and/or aliases
Key: SOLR-4905
URL: https://issues.apache.org/jira/browse/SOLR-4905
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Reporter: Philip K. Warren
Using a non-SolrCloud setup, it is possible to perform cross core joins
(http://wiki.apache.org/solr/Join). When testing with SolrCloud, however,
neither the collection name, alias name (we have created aliases to SolrCloud
collections), or the automatically generated core name (i.e.
collection_shard1_replica1) work as the fromIndex parameter for a
cross-core join.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-4905) Cross core joins don't work for SolrCloud collections and/or aliases
[
https://issues.apache.org/jira/browse/SOLR-4905?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737585#comment-13737585
]
Utkarsh Sengar edited comment on SOLR-4905 at 8/13/13 12:09 AM:
@Chris I have solrcloud 4.4 running with 3 shards and 2 cores. A cross-core
join does not work even when cores are created during the bootstrap time.
This is my query:
{noformat} http://SOLR_SERVER/solr/merchant/select?q={!join from=merchantId
to=merchantId fromIndex=deals}apple {noformat}
This query returns no documents, full response with debugQuery=true:
http://apaste.info/uHOw
But both of my cores have a common merchantId when I query for apple. So I
think this problem is a general problem in solrcloud.
was (Author: zengr):
@Chris I have solrcloud 4.4 running with 3 shards and 2 cores. A cross-core
join does not work even when cores are created during the bootstrap time.
This is my query:
http://SOLR_SERVER/solr/merchant/select?q={!join from=merchantId to=merchantId
fromIndex=deals}apple
This query returns no documents, full response with debugQuery=true:
http://apaste.info/uHOw
But both of my cores have a common merchantId when I query for apple. So I
think this problem is a general problem in solrcloud.
Cross core joins don't work for SolrCloud collections and/or aliases
Key: SOLR-4905
URL: https://issues.apache.org/jira/browse/SOLR-4905
Project: Solr
Issue Type: Improvement
Components: SolrCloud
Reporter: Philip K. Warren
Using a non-SolrCloud setup, it is possible to perform cross core joins
(http://wiki.apache.org/solr/Join). When testing with SolrCloud, however,
neither the collection name, alias name (we have created aliases to SolrCloud
collections), or the automatically generated core name (i.e.
collection_shard1_replica1) work as the fromIndex parameter for a
cross-core join.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-4583) StraightBytesDocValuesField fails if bytes 32k
[
https://issues.apache.org/jira/browse/LUCENE-4583?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737648#comment-13737648
]
Yonik Seeley commented on LUCENE-4583:
--
Another user has hit this arbitrary limit:
http://markmail.org/message/sotbq6xpib4xwozz
If it is arbitrary at this point, we should simply remove it.
StraightBytesDocValuesField fails if bytes 32k
Key: LUCENE-4583
URL: https://issues.apache.org/jira/browse/LUCENE-4583
Project: Lucene - Core
Issue Type: Bug
Components: core/index
Affects Versions: 4.0, 4.1, 5.0
Reporter: David Smiley
Assignee: Michael McCandless
Priority: Critical
Fix For: 5.0, 4.5
Attachments: LUCENE-4583.patch, LUCENE-4583.patch, LUCENE-4583.patch,
LUCENE-4583.patch, LUCENE-4583.patch, LUCENE-4583.patch, LUCENE-4583.patch
I didn't observe any limitations on the size of a bytes based DocValues field
value in the docs. It appears that the limit is 32k, although I didn't get
any friendly error telling me that was the limit. 32k is kind of small IMO;
I suspect this limit is unintended and as such is a bug.The following
test fails:
{code:java}
public void testBigDocValue() throws IOException {
Directory dir = newDirectory();
IndexWriter writer = new IndexWriter(dir, writerConfig(false));
Document doc = new Document();
BytesRef bytes = new BytesRef((4+4)*4097);//4096 works
bytes.length = bytes.bytes.length;//byte data doesn't matter
doc.add(new StraightBytesDocValuesField(dvField, bytes));
writer.addDocument(doc);
writer.commit();
writer.close();
DirectoryReader reader = DirectoryReader.open(dir);
DocValues docValues = MultiDocValues.getDocValues(reader, dvField);
//FAILS IF BYTES IS BIG!
docValues.getSource().getBytes(0, bytes);
reader.close();
dir.close();
}
{code}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4952) audit test configs to use solrconfig.snippet.randomindexconfig.xml in more tests
[
https://issues.apache.org/jira/browse/SOLR-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737700#comment-13737700
]
ASF subversion and git services commented on SOLR-4952:
---
Commit 1513312 from hoss...@apache.org in branch 'dev/trunk'
[ https://svn.apache.org/r1513312 ]
SOLR-4952: make TestConfig use solrconfig.snippet.randomindexconfig.xml - this
involved moving some 'default' tests arround, prunning down
solrconfig-termindex.xml, and renaming solrconfig-termindex.xml -
solrconfig-test-misc.xml since the mane 'termindex' made no sense for what it
is used for
audit test configs to use solrconfig.snippet.randomindexconfig.xml in more
tests
Key: SOLR-4952
URL: https://issues.apache.org/jira/browse/SOLR-4952
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
in SOLR-4942 i updated every solrconfig.xml to either...
* include solrconfig.snippet.randomindexconfig.xml where it was easy to do so
* use the useCompoundFile sys prop if it already had an {{indexConfig}}
section, or if including the snippet wasn't going to be easy (ie: contrib
tests)
As an improvment on this:
* audit all core configs not already using
solrconfig.snippet.randomindexconfig.xml and either:
** make them use it, ignoring any previously unimportant explicit
incdexConfig settings
** make them use it, using explicit sys props to overwrite random values in
cases were explicit indexConfig values are important for test
** add a comment why it's not using the include snippet in cases where the
explicit parsing is part of hte test
* try figure out a way for contrib tests to easily include the same file
and/or apply the same rules as above
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson updated SOLR-4718: - Attachment: SOLR-4718.patch Beefed up the tests, added bits about getting the uploaded solr.xml from the embedded ZK instance. I need to insure that the variations on embedded ZK work manually (unless I can come up with a clever test), but otherwise I think it's ready to commit and I'll probably check it in over the next day or two unless there are objections or I find problems when I look at it with fresh eyes. Allow solr.xml to be stored in zookeeper Key: SOLR-4718 URL: https://issues.apache.org/jira/browse/SOLR-4718 Project: Solr Issue Type: Improvement Components: Schema and Analysis Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Attachments: SOLR-4718.patch, SOLR-4718.patch So the near-final piece of this puzzle is to make solr.xml be storable in Zookeeper. Code-wise in terms of Solr, this doesn't look very difficult, I'm working on it now. More interesting is how to get the configuration into ZK in the first place, enhancements to ZkCli? Or boostrap-conf? Other? I'm punting on that for this patch. Second level is how to tell Solr to get the file from ZK. Some possibilities: 1 A system prop, -DzkSolrXmlPath=blah where blah is the path _on zk_ where the file is. Would require -DzkHost or -DzkRun as well. pros - simple, I can wrap my head around it. - easy to script cons - can't run multiple JVMs pointing to different files. Is this really a problem? 2 New solr.xml element. Something like: solr solrcloud str name=zkHostzkurl/str str name=zkSolrXmlPathwhatever/str /solrcloud solr Really, this form would hinge on the presence or absence of zkSolrXmlPath. If present, go up and look for the indicated solr.xml file on ZK. Any properties in the ZK version would overwrite anything in the local copy. NOTE: I'm really not very interested in supporting this as an option for old-style solr.xml unless it's _really_ easy. For instance, what if the local solr.xml is new-style and the one in ZK is old-style? Or vice-versa? Since old-style is going away, this doesn't seem like it's worth the effort. pros - No new mechanisms cons - once again requires that there be a solr.xml file on each client. Admittedly for installations that didn't care much about multiple JVMs, it could be a stock file that didn't change... For now, I'm going to just manually push solr.xml to ZK, then read it based on a sysprop. That'll get the structure in place while we debate. Not going to check this in until there's some consensus though. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4952) audit test configs to use solrconfig.snippet.randomindexconfig.xml in more tests
[
https://issues.apache.org/jira/browse/SOLR-4952?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737735#comment-13737735
]
ASF subversion and git services commented on SOLR-4952:
---
Commit 1513325 from hoss...@apache.org in branch 'dev/branches/branch_4x'
[ https://svn.apache.org/r1513325 ]
SOLR-4952: make TestConfig use solrconfig.snippet.randomindexconfig.xml - this
involved moving some 'default' tests arround, prunning down
solrconfig-termindex.xml, and renaming solrconfig-termindex.xml -
solrconfig-test-misc.xml since the name 'termindex' no longer makes sense
(merge r1513312)
audit test configs to use solrconfig.snippet.randomindexconfig.xml in more
tests
Key: SOLR-4952
URL: https://issues.apache.org/jira/browse/SOLR-4952
Project: Solr
Issue Type: Sub-task
Reporter: Hoss Man
Assignee: Hoss Man
in SOLR-4942 i updated every solrconfig.xml to either...
* include solrconfig.snippet.randomindexconfig.xml where it was easy to do so
* use the useCompoundFile sys prop if it already had an {{indexConfig}}
section, or if including the snippet wasn't going to be easy (ie: contrib
tests)
As an improvment on this:
* audit all core configs not already using
solrconfig.snippet.randomindexconfig.xml and either:
** make them use it, ignoring any previously unimportant explicit
incdexConfig settings
** make them use it, using explicit sys props to overwrite random values in
cases were explicit indexConfig values are important for test
** add a comment why it's not using the include snippet in cases where the
explicit parsing is part of hte test
* try figure out a way for contrib tests to easily include the same file
and/or apply the same rules as above
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-5017) Allow sharding based on the value of a field
[ https://issues.apache.org/jira/browse/SOLR-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Noble Paul updated SOLR-5017: - Attachment: SOLR-5017.patch suuports routeField in compositeId router Allow sharding based on the value of a field Key: SOLR-5017 URL: https://issues.apache.org/jira/browse/SOLR-5017 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul Fix For: 4.5, 5.0 Attachments: SOLR-5017.patch We should be able to create a collection where sharding is done based on the value of a given field collections can be created with shardField=fieldName, which will be persisted in DocCollection in ZK implicit DocRouter would look at this field instead of _shard_ field CompositeIdDocRouter can also use this field instead of looking at the id field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-3069) Lucene should have an entirely memory resident term dictionary
[ https://issues.apache.org/jira/browse/LUCENE-3069?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737782#comment-13737782 ] ASF subversion and git services commented on LUCENE-3069: - Commit 1513336 from [~billy] in branch 'dev/branches/lucene3069' [ https://svn.apache.org/r1513336 ] LUCENE-3069: merge trunk changes over Lucene should have an entirely memory resident term dictionary -- Key: LUCENE-3069 URL: https://issues.apache.org/jira/browse/LUCENE-3069 Project: Lucene - Core Issue Type: Improvement Components: core/index, core/search Affects Versions: 4.0-ALPHA Reporter: Simon Willnauer Assignee: Han Jiang Labels: gsoc2013 Fix For: 5.0, 4.5 Attachments: df-ttf-estimate.txt, example.png, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch, LUCENE-3069.patch FST based TermDictionary has been a great improvement yet it still uses a delta codec file for scanning to terms. Some environments have enough memory available to keep the entire FST based term dict in memory. We should add a TermDictionary implementation that encodes all needed information for each term into the FST (custom fst.Output) and builds a FST from the entire term not just the delta. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-trunk-MacOSX (64bit/jdk1.7.0) - Build # 726 - Still Failing!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-MacOSX/726/ Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -XX:+UseG1GC All tests passed Build Log: [...truncated 34726 lines...] -documentation-lint: [jtidy] Checking for broken html (such as invalid tags)... [delete] Deleting directory /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/build/jtidy_tmp [echo] Checking for broken links... [exec] [exec] Crawl/parse... [exec] [exec] Verify... [echo] Checking for malformed docs... [exec] [exec] /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/build/docs/solr-core/overview-summary.html [exec] missing: org.apache.solr.search.join [exec] [exec] Missing javadocs were found! BUILD FAILED /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/build.xml:389: The following error occurred while executing this line: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/build.xml:60: The following error occurred while executing this line: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/build.xml:563: The following error occurred while executing this line: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/solr/build.xml:579: The following error occurred while executing this line: /Users/jenkins/jenkins-slave/workspace/Lucene-Solr-trunk-MacOSX/lucene/common-build.xml:2149: exec returned: 1 Total time: 152 minutes 58 seconds Build step 'Invoke Ant' marked build as failure Description set: Java: 64bit/jdk1.7.0 -XX:-UseCompressedOops -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-5017) Allow sharding based on the value of a field
[ https://issues.apache.org/jira/browse/SOLR-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737865#comment-13737865 ] ASF subversion and git services commented on SOLR-5017: --- Commit 1513356 from [~noble.paul] in branch 'dev/trunk' [ https://svn.apache.org/r1513356 ] SOLR-5017 support for routeField in COmpositeId router also Allow sharding based on the value of a field Key: SOLR-5017 URL: https://issues.apache.org/jira/browse/SOLR-5017 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul Fix For: 4.5, 5.0 Attachments: SOLR-5017.patch We should be able to create a collection where sharding is done based on the value of a given field collections can be created with shardField=fieldName, which will be persisted in DocCollection in ZK implicit DocRouter would look at this field instead of _shard_ field CompositeIdDocRouter can also use this field instead of looking at the id field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-5017) Allow sharding based on the value of a field
[ https://issues.apache.org/jira/browse/SOLR-5017?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanelfocusedCommentId=13737869#comment-13737869 ] ASF subversion and git services commented on SOLR-5017: --- Commit 1513357 from [~noble.paul] in branch 'dev/branches/branch_4x' [ https://svn.apache.org/r1513357 ] SOLR-5017 support for routeField in COmpositeId router also Allow sharding based on the value of a field Key: SOLR-5017 URL: https://issues.apache.org/jira/browse/SOLR-5017 Project: Solr Issue Type: Sub-task Reporter: Noble Paul Assignee: Noble Paul Fix For: 4.5, 5.0 Attachments: SOLR-5017.patch We should be able to create a collection where sharding is done based on the value of a given field collections can be created with shardField=fieldName, which will be persisted in DocCollection in ZK implicit DocRouter would look at this field instead of _shard_ field CompositeIdDocRouter can also use this field instead of looking at the id field. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
