[jira] [Updated] (SOLR-4701) CollectorFilterQParserPlugin support Filter Collector at search with PostFilter
[
https://issues.apache.org/jira/browse/SOLR-4701?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Linbin Chen updated SOLR-4701:
--
Description:
example:
* {code}fq={!cf name=in}status:(-1, 2){code}
* {code}fq={!cf name=in not=true}status:(3,4){code}
* {code}fq={!cf name=range}price:[100 TO 500]{code}
* {code}fq={!cf name=range}log(page_view):[50 TO 120]{code}
in operate like sql in， faster then OR boolean query.
most of the case, range faster then TrieField in lucene query.
how to do use:
solrconfig.xml add
{code:xml}
{code}
cf not use query cache, use PostFilter fiter collector
was:
not use query cache example:
* {code}fq={!cf name=in}status:(-1, 2){code}
* {code}fq={!cf name=in not=true}status:(3,4){code}
* {code}fq={!cf name=range}price:[100 TO 500]{code}
* {code}fq={!cf name=range}log(page_view):[50 TO 120]{code}
in operate like sql in， faster then OR boolean query.
most of the case, range faster then TrieField in lucene query.
how to do use:
solrconfig.xml add
{code:xml}
{code}
> CollectorFilterQParserPlugin support Filter Collector at search with
> PostFilter
> ---
>
> Key: SOLR-4701
> URL: https://issues.apache.org/jira/browse/SOLR-4701
> Project: Solr
> Issue Type: New Feature
> Components: search
>Affects Versions: 4.2
>Reporter: Linbin Chen
> Fix For: 4.3
>
> Attachments: SOLR-4701.patch
>
>
> example:
> * {code}fq={!cf name=in}status:(-1, 2){code}
> * {code}fq={!cf name=in not=true}status:(3,4){code}
> * {code}fq={!cf name=range}price:[100 TO 500]{code}
> * {code}fq={!cf name=range}log(page_view):[50 TO 120]{code}
> in operate like sql in， faster then OR boolean query.
> most of the case, range faster then TrieField in lucene query.
> how to do use:
> solrconfig.xml add
> {code:xml}
>
> {code}
> cf not use query cache, use PostFilter fiter collector
--
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-4709) dir lock error if reopening cores to fast?
[
https://issues.apache.org/jira/browse/SOLR-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633765#comment-13633765
]
Mark Miller commented on SOLR-4709:
---
{code}
if (!getNewIndexDir().equals(getIndexDir())) {
// the directory is changing, don't pass on state
prev = null;
}
{code}
This means that if we reopen and the index directory has changed, don't pass on
previous core state - open the core as if it was first starting up. There
should not be a problem getting a lock in that case - this should only happen
when reopening on a *new* index.
I'll spend some time investigating soon.
> dir lock error if reopening cores to fast?
> --
>
> Key: SOLR-4709
> URL: https://issues.apache.org/jira/browse/SOLR-4709
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Mark Miller
> Fix For: 4.3, 5.0
>
>
> While testing my patch for SOLR-4629, i noticed a really random error that i
> traced back to the core reload (do to config file replication) failed because
> the directory was locked.
> From what i can tell, the lock checking code in the SolrCore constructor
> isn't even suppose to be used in the reload situation where there is a "prev"
> core, except that in SolrCore.reload there is this check...
> {noformat}
> if (!getNewIndexDir().equals(getIndexDir())) {
> // the directory is changing, don't pass on state
> prev = null;
> }
> {noformat}
> ..i'm not really sure i understand this logic, or what exactly the source of
> the problem is, or if the lock checking code should just be changed to work a
> differnet way completley, but it seemed worthy of tracking in it's own jira.
> log details to follow
--
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-4727) Exception throws when using collection aliases and ClouldSolrServer
[ https://issues.apache.org/jira/browse/SOLR-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633738#comment-13633738 ] Mark Miller commented on SOLR-4727: --- By the way, you can work around it by making the update call yourself. > Exception throws when using collection aliases and ClouldSolrServer > --- > > Key: SOLR-4727 > URL: https://issues.apache.org/jira/browse/SOLR-4727 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.2 >Reporter: ShiJie Mao > Fix For: 4.2 > > > [2013-04-16 18:27:18] ERROR org.apache.solr.core.SolrCore - > org.apache.solr.common.SolrException: Could not find > collection:test_collection > at > org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:136) > at > org.apache.solr.handler.component.HttpShardHandler.addSlices(HttpShardHandler.java:414) > at > org.apache.solr.handler.component.HttpShardHandler.checkDistributed(HttpShardHandler.java:315) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:182) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1797) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:637) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:141) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:989) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579) > at > org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1763) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > SolrDispatchFilter#doFilter didn't update collection aliase correctly. > When using CloudSolrServer client, the core is not null at > SolrDispatchFilter.java line 239. > So ZkStateReader#updateAliases wasn't called. -- 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-4727) Exception throws when using collection aliases and ClouldSolrServer
[ https://issues.apache.org/jira/browse/SOLR-4727?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633737#comment-13633737 ] Mark Miller commented on SOLR-4727: --- I think this is a dupe issue and will be fixed in the upcoming 4.3 release. > Exception throws when using collection aliases and ClouldSolrServer > --- > > Key: SOLR-4727 > URL: https://issues.apache.org/jira/browse/SOLR-4727 > Project: Solr > Issue Type: Bug > Components: SolrCloud >Affects Versions: 4.2 >Reporter: ShiJie Mao > Fix For: 4.2 > > > [2013-04-16 18:27:18] ERROR org.apache.solr.core.SolrCore - > org.apache.solr.common.SolrException: Could not find > collection:test_collection > at > org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:136) > at > org.apache.solr.handler.component.HttpShardHandler.addSlices(HttpShardHandler.java:414) > at > org.apache.solr.handler.component.HttpShardHandler.checkDistributed(HttpShardHandler.java:315) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:182) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1797) > at > org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:637) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343) > at > org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:141) > at > org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) > at > org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) > at > org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224) > at > org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169) > at > org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) > at > org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) > at > org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) > at > org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) > at > org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:989) > at > org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579) > at > org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1763) > at > java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) > at java.lang.Thread.run(Thread.java:662) > SolrDispatchFilter#doFilter didn't update collection aliase correctly. > When using CloudSolrServer client, the core is not null at > SolrDispatchFilter.java line 239. > So ZkStateReader#updateAliases wasn't called. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[JENKINS] Lucene-Solr-4.x-Linux (32bit/jrockit-jdk1.6.0_37-R28.2.5-4.1.0) - Build # 5151 - Failure!
Build: http://jenkins.thetaphi.de/job/Lucene-Solr-4.x-Linux/5151/ Java: 32bit/jrockit-jdk1.6.0_37-R28.2.5-4.1.0 -XnoOpt 1 tests failed. REGRESSION: org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues Error Message: allocLargeObjectOrArray: [Ljava/lang/Object;, larger than Java heap Stack Trace: java.lang.OutOfMemoryError: allocLargeObjectOrArray: [Ljava/lang/Object;, larger than Java heap at __randomizedtesting.SeedInfo.seed([C51CBF03ECC25CBF:3B7CFEC65405DB0F]:0) at org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:64) at org.apache.lucene.util.PriorityQueue.(PriorityQueue.java:37) at org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:138) at org.apache.lucene.search.FieldValueHitQueue.(FieldValueHitQueue.java:34) at org.apache.lucene.search.FieldValueHitQueue$OneComparatorFieldValueHitQueue.(FieldValueHitQueue.java:63) at org.apache.lucene.search.FieldValueHitQueue.create(FieldValueHitQueue.java:171) at org.apache.lucene.search.TopFieldCollector.create(TopFieldCollector.java:1123) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:526) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:501) at org.apache.lucene.search.IndexSearcher.search(IndexSearcher.java:378) at org.apache.lucene.queries.function.TestFunctionQuerySort.testSearchAfterWhenSortingByFunctionValues(TestFunctionQuerySort.java:72) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) 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 org.apache.lucene.util.TestRuleAssertionsRequired$1.evaluate(TestRuleAssertionsRequired.java:43) at org.apache.lucene.util.TestRuleMarkFailure$1.evaluate(TestRuleMarkFailure.java:48) at org.apache.lucene.util.TestRuleIgnoreAfterMaxFailures$1.evaluate(TestRuleIgn
[jira] [Created] (SOLR-4727) Exception throws when using collection aliases and ClouldSolrServer
ShiJie Mao created SOLR-4727: Summary: Exception throws when using collection aliases and ClouldSolrServer Key: SOLR-4727 URL: https://issues.apache.org/jira/browse/SOLR-4727 Project: Solr Issue Type: Bug Components: SolrCloud Affects Versions: 4.2 Reporter: ShiJie Mao Fix For: 4.2 [2013-04-16 18:27:18] ERROR org.apache.solr.core.SolrCore - org.apache.solr.common.SolrException: Could not find collection:test_collection at org.apache.solr.common.cloud.ClusterState.getCollection(ClusterState.java:136) at org.apache.solr.handler.component.HttpShardHandler.addSlices(HttpShardHandler.java:414) at org.apache.solr.handler.component.HttpShardHandler.checkDistributed(HttpShardHandler.java:315) at org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:182) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) at org.apache.solr.core.SolrCore.execute(SolrCore.java:1797) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.java:637) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:343) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.java:141) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:243) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:210) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:224) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:169) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:168) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:98) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:118) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:407) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:989) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:579) at org.apache.tomcat.util.net.AprEndpoint$SocketWithOptionsProcessor.run(AprEndpoint.java:1763) at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) at java.lang.Thread.run(Thread.java:662) SolrDispatchFilter#doFilter didn't update collection aliase correctly. When using CloudSolrServer client, the core is not null at SolrDispatchFilter.java line 239. So ZkStateReader#updateAliases wasn't called. -- 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-3251) dynamically add fields to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Steve Rowe updated SOLR-3251: - Fix Version/s: 5.0 Summary: dynamically add fields to schema (was: dynamically add field to schema) > dynamically add fields to schema > > > Key: SOLR-3251 > URL: https://issues.apache.org/jira/browse/SOLR-3251 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Steve Rowe > Fix For: 4.3, 5.0 > > Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch, > SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch > > > One related piece of functionality needed for SOLR-3250 is the ability to > dynamically add a field to the schema. -- 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-3251) dynamically add field to schema
[ https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633720#comment-13633720 ] Steve Rowe commented on SOLR-3251: -- bq. This is not the full refactoring with an abstract IndexSchema, but at least these methods won't get in the way of that. I'll make a separate JIRA for the schema refactoring so the idea doesn't get lost. See SOLR-4726 > dynamically add field to schema > --- > > Key: SOLR-3251 > URL: https://issues.apache.org/jira/browse/SOLR-3251 > Project: Solr > Issue Type: New Feature >Reporter: Yonik Seeley >Assignee: Steve Rowe > Fix For: 4.3 > > Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch, > SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch > > > One related piece of functionality needed for SOLR-3250 is the ability to > dynamically add a field to the schema. -- 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-4726) Factor out a minimal abstract class from IndexSchema/ManagedIndexSchema
Steve Rowe created SOLR-4726:
Summary: Factor out a minimal abstract class from
IndexSchema/ManagedIndexSchema
Key: SOLR-4726
URL: https://issues.apache.org/jira/browse/SOLR-4726
Project: Solr
Issue Type: Task
Components: Schema and Analysis
Reporter: Steve Rowe
Priority: Minor
Spinoff from SOLR-3251.
[~rcmuir] wrote, on SOLR-4658 and SOLR-3251:
{quote}
If the goal is to have multiple implementations of indexschema (immutable ones
backed by human edited files, mutable ones saved to some opaque "database" that
can be edited by REST), then why not make IndexSchema abstract and pluggable
from solrconfig.xml like anything else?
{quote}
{quote}
So IndexSchema becomes abstract and loaded just like other plugins, versus
being a "wonder-do-it-all" class. It would also
have the advantage of not having a bunch of options that have illegal
combinations (e.g. managed+mutable)
Finally it makes it extensible: if someone wants to make their own impl that is
powered by microsoft access .MDB files then
they can do so.
(Also i think it would make backwards compatibility possible in case something
changes in drastic ways).
{quote}
{quote}
and it would also be a bonus in the future if somehow the backwards cruft
existing in various FieldType etc apis (e.g. defaults and so on) were factored
into the Classic guy to keep those apis simpler...
{quote}
{quote}
>From a pluggability perspective it would be nice if e.g. addFields was
>factored down (e.g. IndexSchema becomes abstract and minimal), and the
>immutable default impl threw UOE for changes or whatever... But i know this is
>a lot of work, it would be a good followup issue and probably good to do
>before schema gets any more hair (there is already tons of backwards cruft
>thrown about it for compat etc too).
{quote}
--
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-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
[ https://issues.apache.org/jira/browse/SOLR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633709#comment-13633709 ] Mark Miller edited comment on SOLR-4725 at 4/17/13 3:12 AM: Okay, wait - you don't mean dataDir in solrconfig.xml. In that case, I'm confused...was their explicit support for dataDir in solr.xml before? I thought it was just basic property support so that if you setup solrconfig.xml to take a prop substitution, you could then set those properties in solr.xml with the generic Should we stop supporting "name" and "dataDir" in the autodiscover mode? > > > Key: SOLR-4725 > URL: https://issues.apache.org/jira/browse/SOLR-4725 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > > Making this a blocker so we resolve it. Should be quick to code if we have > consensus, maybe nothing at all to do here. > I'm not too happy with the fact that the new core discovery process has two > real gotcha's. The individual core.properties file can define 'name' and > 'dataDir'. It seems too easy to either use the same name for two different > cores or use the same dataDir, just copy the core.properties file around and > fail to edit one them. In large installations this could be a bear to track > down. > Straw-man proposal is the we remove support for them both in discovery mode. > The name defaults to the directory in which core.properties is found and the > data dir is immediately below there. > Currently, there are checks to fail to load either core if either 'name' or > 'dataDir' is defined in more than one core. I think the error reporting is > weak, you probably have to look in the log file and there should be a way to > get this in the admin UI at least. > Maybe the right thing to do is just leave it as-is and emphasize that > specifying the dataDir and name is expert level and you have to get it right, > but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
[ https://issues.apache.org/jira/browse/SOLR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633709#comment-13633709 ] Mark Miller commented on SOLR-4725: --- Okay, wait - you don't mean dataDir in solrconfig.xml. In that case, I'm confused...was their explicit support for dataDir in solr.xml before? I thought it was just basic property support so that if you setup solrconfig.xml to take a prop substitution, you could then set those properties in solr.xml with the generic Should we stop supporting "name" and "dataDir" in the autodiscover mode? > > > Key: SOLR-4725 > URL: https://issues.apache.org/jira/browse/SOLR-4725 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > > Making this a blocker so we resolve it. Should be quick to code if we have > consensus, maybe nothing at all to do here. > I'm not too happy with the fact that the new core discovery process has two > real gotcha's. The individual core.properties file can define 'name' and > 'dataDir'. It seems too easy to either use the same name for two different > cores or use the same dataDir, just copy the core.properties file around and > fail to edit one them. In large installations this could be a bear to track > down. > Straw-man proposal is the we remove support for them both in discovery mode. > The name defaults to the directory in which core.properties is found and the > data dir is immediately below there. > Currently, there are checks to fail to load either core if either 'name' or > 'dataDir' is defined in more than one core. I think the error reporting is > weak, you probably have to look in the log file and there should be a way to > get this in the admin UI at least. > Maybe the right thing to do is just leave it as-is and emphasize that > specifying the dataDir and name is expert level and you have to get it right, > but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
[ https://issues.apache.org/jira/browse/SOLR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633705#comment-13633705 ] Mark Miller commented on SOLR-4725: --- bq. Currently, there are checks to fail to load either core if either 'name' or 'dataDir' is defined in more than one core. Why? You should be able to specify dataDir in more than one core. > Should we stop supporting "name" and "dataDir" in the autodiscover mode? > > > Key: SOLR-4725 > URL: https://issues.apache.org/jira/browse/SOLR-4725 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > > Making this a blocker so we resolve it. Should be quick to code if we have > consensus, maybe nothing at all to do here. > I'm not too happy with the fact that the new core discovery process has two > real gotcha's. The individual core.properties file can define 'name' and > 'dataDir'. It seems too easy to either use the same name for two different > cores or use the same dataDir, just copy the core.properties file around and > fail to edit one them. In large installations this could be a bear to track > down. > Straw-man proposal is the we remove support for them both in discovery mode. > The name defaults to the directory in which core.properties is found and the > data dir is immediately below there. > Currently, there are checks to fail to load either core if either 'name' or > 'dataDir' is defined in more than one core. I think the error reporting is > weak, you probably have to look in the log file and there should be a way to > get this in the admin UI at least. > Maybe the right thing to do is just leave it as-is and emphasize that > specifying the dataDir and name is expert level and you have to get it right, > but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
[ https://issues.apache.org/jira/browse/SOLR-4725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633703#comment-13633703 ] Mark Miller commented on SOLR-4725: --- I think dataDir should continue to be supported. There is not much reason to rip it. name should be removed. > Should we stop supporting "name" and "dataDir" in the autodiscover mode? > > > Key: SOLR-4725 > URL: https://issues.apache.org/jira/browse/SOLR-4725 > Project: Solr > Issue Type: New Feature >Affects Versions: 4.3, 5.0 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Blocker > > Making this a blocker so we resolve it. Should be quick to code if we have > consensus, maybe nothing at all to do here. > I'm not too happy with the fact that the new core discovery process has two > real gotcha's. The individual core.properties file can define 'name' and > 'dataDir'. It seems too easy to either use the same name for two different > cores or use the same dataDir, just copy the core.properties file around and > fail to edit one them. In large installations this could be a bear to track > down. > Straw-man proposal is the we remove support for them both in discovery mode. > The name defaults to the directory in which core.properties is found and the > data dir is immediately below there. > Currently, there are checks to fail to load either core if either 'name' or > 'dataDir' is defined in more than one core. I think the error reporting is > weak, you probably have to look in the log file and there should be a way to > get this in the admin UI at least. > Maybe the right thing to do is just leave it as-is and emphasize that > specifying the dataDir and name is expert level and you have to get it right, > but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b84) - Build # 5202 - Failure!
Some tests fail when run under java 8. - Mark On Apr 16, 2013, at 9:29 PM, Ryan McKinley wrote: > Are these "real" errors that I should worry about? > > Is it still expected behavior that any *Zk* test that fails is just noise? > > > > wrote: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5202/ > Java: 32bit/jdk1.8.0-ea-b84 -client -XX:+UseG1GC > > 3 tests failed. > FAILED: org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch > > > - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-3251) dynamically add field to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Steve Rowe updated SOLR-3251:
-
Attachment: SOLR-3251.patch
Patch, fixing issues Robert and Yonik raised.
# Restored SchemaCodecFactory's and SchemaSimilarityFactory's not-null
assertions in their getters.
# Moved zkIndexSchemaReader to ManagedIndexSchemaFactory.
# Removed SolrIndexSearcher.getSchema() entirely, switching previous calls to
either pull the schema from the request, if available or failing that, from the
searcher's SolrCore.
# Put {{newField()}} and {{addFields()}} back as member functions of
IndexSchema, rather than static methods on ManagedIndexSchema. This is not the
full refactoring with an abstract IndexSchema, but at least these methods won't
get in the way of that. I'll make a separate JIRA for the schema refactoring
so the idea doesn't get lost.
# Fixed javadoc duplication on SchemaAware {{inform()}} methods.
# In RealTimeGetComponent, switched from {{req.getCore().getSchema()}} to
{{req.getSchem()}}. Added a basic test in new class TestAddFieldRealTimeGet to
make sure this works.
> dynamically add field to schema
> ---
>
> Key: SOLR-3251
> URL: https://issues.apache.org/jira/browse/SOLR-3251
> Project: Solr
> Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Steve Rowe
> Fix For: 4.3
>
> Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch,
> SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch
>
>
> One related piece of functionality needed for SOLR-3250 is the ability to
> dynamically add a field to the schema.
--
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-4487) SolrException usage in solrj client code can't handle all possible http error codes returned by servers -- example "413 Request Entity Too Large"
[ https://issues.apache.org/jira/browse/SOLR-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man resolved SOLR-4487. Resolution: Fixed Fix Version/s: 5.0 Committed revision 1468705. Committed revision 1468718. > SolrException usage in solrj client code can't handle all possible http error > codes returned by servers -- example "413 Request Entity Too Large" > - > > Key: SOLR-4487 > URL: https://issues.apache.org/jira/browse/SOLR-4487 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 4.0 >Reporter: Alexander Dietrich >Assignee: Hoss Man > Fix For: 4.3, 5.0 > > Attachments: SOLR-4487.patch > > > Solr responds to excessively large queries with a 413 status code, but > HttpSolrServer.request() loses this information when it tries to look up the > code in SolrException.ErrorCode, resulting in a status code 0 in the thrown > exception. > Being able to see this status code would be helpful. -- 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-4725) Should we stop supporting "name" and "dataDir" in the autodiscover mode?
Erick Erickson created SOLR-4725: Summary: Should we stop supporting "name" and "dataDir" in the autodiscover mode? Key: SOLR-4725 URL: https://issues.apache.org/jira/browse/SOLR-4725 Project: Solr Issue Type: New Feature Affects Versions: 4.3, 5.0 Reporter: Erick Erickson Assignee: Erick Erickson Priority: Blocker Making this a blocker so we resolve it. Should be quick to code if we have consensus, maybe nothing at all to do here. I'm not too happy with the fact that the new core discovery process has two real gotcha's. The individual core.properties file can define 'name' and 'dataDir'. It seems too easy to either use the same name for two different cores or use the same dataDir, just copy the core.properties file around and fail to edit one them. In large installations this could be a bear to track down. Straw-man proposal is the we remove support for them both in discovery mode. The name defaults to the directory in which core.properties is found and the data dir is immediately below there. Currently, there are checks to fail to load either core if either 'name' or 'dataDir' is defined in more than one core. I think the error reporting is weak, you probably have to look in the log file and there should be a way to get this in the admin UI at least. Maybe the right thing to do is just leave it as-is and emphasize that specifying the dataDir and name is expert level and you have to get it right, but I wanted to get wider exposure to the problem before we push 4.3 out. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
Re: [JENKINS] Lucene-Solr-trunk-Linux (32bit/jdk1.8.0-ea-b84) - Build # 5202 - Failure!
Are these "real" errors that I should worry about? Is it still expected behavior that any *Zk* test that fails is just noise? wrote: > Build: http://jenkins.thetaphi.de/job/Lucene-Solr-trunk-Linux/5202/ > Java: 32bit/jdk1.8.0-ea-b84 -client -XX:+UseG1GC > > 3 tests failed. > FAILED: org.apache.solr.cloud.BasicDistributedZk2Test.testDistribSearch > >
[jira] [Commented] (SOLR-4408) Server hanging on startup
[ https://issues.apache.org/jira/browse/SOLR-4408?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633638#comment-13633638 ] Raintung Li commented on SOLR-4408: --- It is different bug with SOLR-4400. Can remove the link. > Server hanging on startup > - > > Key: SOLR-4408 > URL: https://issues.apache.org/jira/browse/SOLR-4408 > Project: Solr > Issue Type: Bug >Affects Versions: 4.1 > Environment: OpenJDK 64-Bit Server VM (23.2-b09 mixed mode) > Tomcat 7.0 > Eclipse Juno + WTP >Reporter: Francois-Xavier Bonnet >Assignee: Erick Erickson > Fix For: 4.3 > > Attachments: patch-4408.txt > > > While starting, the server hangs indefinitely. Everything works fine when I > first start the server with no index created yet but if I fill the index then > stop and start the server, it hangs. Could it be a lock that is never > released? > Here is what I get in a full thread dump: > 2013-02-06 16:28:52 > Full thread dump OpenJDK 64-Bit Server VM (23.2-b09 mixed mode): > "searcherExecutor-4-thread-1" prio=10 tid=0x7fbdfc16a800 nid=0x42c6 in > Object.wait() [0x7fbe0ab1] >java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0xc34c1c48> (a java.lang.Object) > at java.lang.Object.wait(Object.java:503) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1492) > - locked <0xc34c1c48> (a java.lang.Object) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1312) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1247) > at > org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:94) > at > org.apache.solr.handler.component.QueryComponent.process(QueryComponent.java:213) > at > org.apache.solr.spelling.SpellCheckCollator.collate(SpellCheckCollator.java:112) > at > org.apache.solr.handler.component.SpellCheckComponent.addCollationsToResponse(SpellCheckComponent.java:203) > at > org.apache.solr.handler.component.SpellCheckComponent.process(SpellCheckComponent.java:180) > at > org.apache.solr.handler.component.SearchHandler.handleRequestBody(SearchHandler.java:208) > at > org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:135) > at org.apache.solr.core.SolrCore.execute(SolrCore.java:1816) > at > org.apache.solr.core.QuerySenderListener.newSearcher(QuerySenderListener.java:64) > at org.apache.solr.core.SolrCore$5.call(SolrCore.java:1594) > at java.util.concurrent.FutureTask$Sync.innerRun(FutureTask.java:334) > at java.util.concurrent.FutureTask.run(FutureTask.java:166) > at > java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1110) > at > java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:603) > at java.lang.Thread.run(Thread.java:722) > "coreLoadExecutor-3-thread-1" prio=10 tid=0x7fbe04194000 nid=0x42c5 in > Object.wait() [0x7fbe0ac11000] >java.lang.Thread.State: WAITING (on object monitor) > at java.lang.Object.wait(Native Method) > - waiting on <0xc34c1c48> (a java.lang.Object) > at java.lang.Object.wait(Object.java:503) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1492) > - locked <0xc34c1c48> (a java.lang.Object) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1312) > at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:1247) > at > org.apache.solr.handler.ReplicationHandler.getIndexVersion(ReplicationHandler.java:495) > at > org.apache.solr.handler.ReplicationHandler.getStatistics(ReplicationHandler.java:518) > at > org.apache.solr.core.JmxMonitoredMap$SolrDynamicMBean.getMBeanInfo(JmxMonitoredMap.java:232) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.getNewMBeanClassName(DefaultMBeanServerInterceptor.java:333) > at > com.sun.jmx.interceptor.DefaultMBeanServerInterceptor.registerMBean(DefaultMBeanServerInterceptor.java:319) > at > com.sun.jmx.mbeanserver.JmxMBeanServer.registerMBean(JmxMBeanServer.java:512) > at org.apache.solr.core.JmxMonitoredMap.put(JmxMonitoredMap.java:140) > at org.apache.solr.core.JmxMonitoredMap.put(JmxMonitoredMap.java:51) > at > org.apache.solr.core.SolrResourceLoader.inform(SolrResourceLoader.java:636) > at org.apache.solr.core.SolrCore.(SolrCore.java:809) > at org.apache.solr.core.SolrCore.(SolrCore.java:607) > at > org.apache.solr.core.CoreContainer.createFromLocal(CoreContainer.java:1003) > at org.apache.solr.core.CoreContainer.create(CoreContainer.java:1033) > at org.apache.solr.core.CoreContainer$3.
[jira] [Commented] (SOLR-4709) dir lock error if reopening cores to fast?
[
https://issues.apache.org/jira/browse/SOLR-4709?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633615#comment-13633615
]
Hoss Man commented on SOLR-4709:
Mark: do you have any specific ideas about whether the SolrCore.reload logic
that sets "prev = null" is a bug, or do we need to deal with this in some other
way in SnapPuller?
ie: is there a bug here to fix in SolrCore; or should SnapPuller include retry
logic if the core reload fails; or both?
> dir lock error if reopening cores to fast?
> --
>
> Key: SOLR-4709
> URL: https://issues.apache.org/jira/browse/SOLR-4709
> Project: Solr
> Issue Type: Bug
>Reporter: Hoss Man
>Assignee: Mark Miller
> Fix For: 4.3, 5.0
>
>
> While testing my patch for SOLR-4629, i noticed a really random error that i
> traced back to the core reload (do to config file replication) failed because
> the directory was locked.
> From what i can tell, the lock checking code in the SolrCore constructor
> isn't even suppose to be used in the reload situation where there is a "prev"
> core, except that in SolrCore.reload there is this check...
> {noformat}
> if (!getNewIndexDir().equals(getIndexDir())) {
> // the directory is changing, don't pass on state
> prev = null;
> }
> {noformat}
> ..i'm not really sure i understand this logic, or what exactly the source of
> the problem is, or if the lock checking code should just be changed to work a
> differnet way completley, but it seemed worthy of tracking in it's own jira.
> log details to follow
--
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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633575#comment-13633575 ] Mark Miller commented on SOLR-4718: --- bq. given the assumptions it's pretty straight-forward. I'm pretty sure it is, just because it's so close to what is already done with solrcore.properties. bq. a> solr.xml is a local file. Apply local solr.properties only if new-style (changes when we stop supporting old-style solr.xml). Stop Yeah, I think only new style is fine. Look how this is done with solrcore.properties - that's a good starting point. bq. b> zkhost is specified as a sysprop. Read solr.xml from ZK. If found, apply local solr.properties (if any) and stop. Right - as part of loading the solr.xml file you should be able to just pass along the props you read like solrcore.properties. bq. c> zkhost is specified in local solr.properties. Use it to get solr.xml from ZK. If found, apply local solr.properties (if any) and stop Right, the zkhost exception - we just first try and find it in this prop file if it exists and zkhost is not found as a sys prop. bq. d> Use the current hard-coded old-style solr.xml file. Do NOT apply any local solr.properties (this will change when we stop supporting old-style solr.xml). Yeah, that's back compat support and we don't need to add features for it IMO. > 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 > > 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: > > > zkurl > whatever > > >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-4358) SolrJ, by preventing multi-part post, loses key information about file name that Tika needs
[ https://issues.apache.org/jira/browse/SOLR-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633558#comment-13633558 ] Uwe Schindler commented on SOLR-4358: - Thanks, I reenabled Jenkins builds. > SolrJ, by preventing multi-part post, loses key information about file name > that Tika needs > --- > > Key: SOLR-4358 > URL: https://issues.apache.org/jira/browse/SOLR-4358 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Karl Wright >Assignee: Ryan McKinley > Attachments: SOLR-4358.patch, SOLR-4358.patch > > > SolrJ accepts a ContentStream, which has a name field. Within > HttpSolrServer.java, if SolrJ makes the decision to use multipart posts, this > filename is transmitted as part of the form boundary information. However, > if SolrJ chooses not to use multipart post, the filename information is lost. > This information is used by SolrCell (Tika) to make decisions about content > extraction, so it is very important that it makes it into Solr in one way or > another. Either SolrJ should set appropriate equivalent headers to send the > filename automatically, or it should force multipart posts when this > information is present. -- 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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633557#comment-13633557 ] Erick Erickson commented on SOLR-4718: -- There is no problem I can't make unnecessarily complex... Let me take a whack at it, as you say given the assumptions it's pretty straight-forward. Here's the rules then: a> solr.xml is a local file. Apply local solr.properties only if new-style (changes when we stop supporting old-style solr.xml). Stop b> zkhost is specified as a sysprop. Read solr.xml from ZK. If found, apply local solr.properties (if any) and stop. c> zkhost is specified in local solr.properties. Use it to get solr.xml from ZK. If found, apply local solr.properties (if any) and stop d> Use the current hard-coded old-style solr.xml file. Do NOT apply any local solr.properties (this will change when we stop supporting old-style solr.xml). > 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 > > 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: > > > zkurl > whatever > > >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-4358) SolrJ, by preventing multi-part post, loses key information about file name that Tika needs
[ https://issues.apache.org/jira/browse/SOLR-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633556#comment-13633556 ] Ryan McKinley commented on SOLR-4358: - reverted in trunk & 4.x I can't figure out what is causing the problem though... will keep digging. > SolrJ, by preventing multi-part post, loses key information about file name > that Tika needs > --- > > Key: SOLR-4358 > URL: https://issues.apache.org/jira/browse/SOLR-4358 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Karl Wright >Assignee: Ryan McKinley > Attachments: SOLR-4358.patch, SOLR-4358.patch > > > SolrJ accepts a ContentStream, which has a name field. Within > HttpSolrServer.java, if SolrJ makes the decision to use multipart posts, this > filename is transmitted as part of the form boundary information. However, > if SolrJ chooses not to use multipart post, the filename information is lost. > This information is used by SolrCell (Tika) to make decisions about content > extraction, so it is very important that it makes it into Solr in one way or > another. Either SolrJ should set appropriate equivalent headers to send the > filename automatically, or it should force multipart posts when this > information is present. -- 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-4724) Highlighting per field selected with hl.q
[
https://issues.apache.org/jira/browse/SOLR-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633542#comment-13633542
]
Karol Sikora commented on SOLR-4724:
Thanks, that works. But I would discuss this behaviour - when I provide hl.q
maybe hl.requireFieldMatch should be assumed to be true?
> Highlighting per field selected with hl.q
> -
>
> Key: SOLR-4724
> URL: https://issues.apache.org/jira/browse/SOLR-4724
> Project: Solr
> Issue Type: New Feature
> Components: highlighter
>Affects Versions: 4.2
>Reporter: Karol Sikora
>
> It would be nice to have when highlighter will honor fields provided in hl.q.
> For example:
> hl.q: title:Lorem ipsum OR creator:Some creator
> hl.fl:title,creator
> I recive both phrases ("Lorem ipsum" and "Some creator") highlighted in both
> fields, so if phrase "Lorem ipsum" exists in creator field it is also
> highlighted. I expect to have highlighted only "Lorem ipsum" in title field
> and "Some author" in creator field. I'm not sure if it's desired behavior of
> solr highligter or bug, please confirm.
--
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-4724) Highlighting per field selected with hl.q
[
https://issues.apache.org/jira/browse/SOLR-4724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Hoss Man resolved SOLR-4724.
Resolution: Not A Problem
This is exactly what "hl.requireFieldMatch=false|true" does. Compare the
results of these queries using hte 4.2 sample data...
*
http://localhost:8983/solr/collection1/select?q=name:apple+OR+features:memory&fl=id,name,features&hl=true&hl.fl=name,features&hl.requireFieldMatch=false
*
http://localhost:8983/solr/collection1/select?q=name:apple+OR+features:memory&fl=id,name,features&hl=true&hl.fl=name,features&hl.requireFieldMatch=true
> Highlighting per field selected with hl.q
> -
>
> Key: SOLR-4724
> URL: https://issues.apache.org/jira/browse/SOLR-4724
> Project: Solr
> Issue Type: New Feature
> Components: highlighter
>Affects Versions: 4.2
>Reporter: Karol Sikora
>
> It would be nice to have when highlighter will honor fields provided in hl.q.
> For example:
> hl.q: title:Lorem ipsum OR creator:Some creator
> hl.fl:title,creator
> I recive both phrases ("Lorem ipsum" and "Some creator") highlighted in both
> fields, so if phrase "Lorem ipsum" exists in creator field it is also
> highlighted. I expect to have highlighted only "Lorem ipsum" in title field
> and "Some author" in creator field. I'm not sure if it's desired behavior of
> solr highligter or bug, please confirm.
--
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-4722) Highlighter which generates a list of query term position(s) for each item in a list of documents, or returns null if highlighting is disabled.
[ https://issues.apache.org/jira/browse/SOLR-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633530#comment-13633530 ] Karol Sikora commented on SOLR-4722: Very usefull feature, thanks Tricia! > Highlighter which generates a list of query term position(s) for each item in > a list of documents, or returns null if highlighting is disabled. > --- > > Key: SOLR-4722 > URL: https://issues.apache.org/jira/browse/SOLR-4722 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 4.3, 5.0 >Reporter: Tricia Jenkins >Priority: Minor > Attachments: SOLR-4722.patch, solr-positionshighlighter.jar > > > As an alternative to returning snippets, this highlighter provides the (term) > position for query matches. One usecase for this is to reconcile the term > position from the Solr index with 'word' coordinates provided by an OCR > process. In this way we are able to 'highlight' an image, like a page from a > book or an article from a newspaper, in the locations that match the user's > query. > This is based on the FastVectorHighlighter and requires that termVectors, > termOffsets and termPositions be stored. -- 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-4724) Highlighting per field selected with hl.q
Karol Sikora created SOLR-4724:
--
Summary: Highlighting per field selected with hl.q
Key: SOLR-4724
URL: https://issues.apache.org/jira/browse/SOLR-4724
Project: Solr
Issue Type: New Feature
Components: highlighter
Affects Versions: 4.2
Reporter: Karol Sikora
It would be nice to have when highlighter will honor fields provided in hl.q.
For example:
hl.q: title:Lorem ipsum OR creator:Some creator
hl.fl:title,creator
I recive both phrases ("Lorem ipsum" and "Some creator") highlighted in both
fields, so if phrase "Lorem ipsum" exists in creator field it is also
highlighted. I expect to have highlighted only "Lorem ipsum" in title field and
"Some author" in creator field. I'm not sure if it's desired behavior of solr
highligter or bug, please confirm.
--
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-4358) SolrJ, by preventing multi-part post, loses key information about file name that Tika needs
[ https://issues.apache.org/jira/browse/SOLR-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633522#comment-13633522 ] Uwe Schindler commented on SOLR-4358: - I stopped Jenkins builds until this is fixed/reverted, because the Windows Jenkins machine needed to be killed hard because ChaosMonkeySafeLeaderTest was eating all virtual CPUs available, making it impossible to shut down the virtual machine or stop tests other than hitting the virtual PowerOff button :( Under Linux, only kill -9 stops ChaosMonkey. > SolrJ, by preventing multi-part post, loses key information about file name > that Tika needs > --- > > Key: SOLR-4358 > URL: https://issues.apache.org/jira/browse/SOLR-4358 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Karl Wright >Assignee: Ryan McKinley > Attachments: SOLR-4358.patch, SOLR-4358.patch > > > SolrJ accepts a ContentStream, which has a name field. Within > HttpSolrServer.java, if SolrJ makes the decision to use multipart posts, this > filename is transmitted as part of the form boundary information. However, > if SolrJ chooses not to use multipart post, the filename information is lost. > This information is used by SolrCell (Tika) to make decisions about content > extraction, so it is very important that it makes it into Solr in one way or > another. Either SolrJ should set appropriate equivalent headers to send the > filename automatically, or it should force multipart posts when this > information is present. -- 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-2341) Shard distribution policy
[ https://issues.apache.org/jira/browse/SOLR-2341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633518#comment-13633518 ] Furkan KAMACI commented on SOLR-2341: - Does new policy considers about document size of a shard? If one shard has much more documents than others there may occur a bottleneck so does it avoid it? > Shard distribution policy > - > > Key: SOLR-2341 > URL: https://issues.apache.org/jira/browse/SOLR-2341 > Project: Solr > Issue Type: New Feature > Components: SolrCloud >Reporter: William Mayor >Priority: Minor > Fix For: 4.3 > > Attachments: SOLR-2341.patch, SOLR-2341.patch > > > A first crack at creating policies to be used for determining to which of a > list of shards a document should go. See discussion on "Distributed Indexing" > on dev-list. -- 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-4358) SolrJ, by preventing multi-part post, loses key information about file name that Tika needs
[ https://issues.apache.org/jira/browse/SOLR-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633516#comment-13633516 ] Ryan McKinley commented on SOLR-4358: - sorry... digging now... > SolrJ, by preventing multi-part post, loses key information about file name > that Tika needs > --- > > Key: SOLR-4358 > URL: https://issues.apache.org/jira/browse/SOLR-4358 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Karl Wright >Assignee: Ryan McKinley > Attachments: SOLR-4358.patch, SOLR-4358.patch > > > SolrJ accepts a ContentStream, which has a name field. Within > HttpSolrServer.java, if SolrJ makes the decision to use multipart posts, this > filename is transmitted as part of the form boundary information. However, > if SolrJ chooses not to use multipart post, the filename information is lost. > This information is used by SolrCell (Tika) to make decisions about content > extraction, so it is very important that it makes it into Solr in one way or > another. Either SolrJ should set appropriate equivalent headers to send the > filename automatically, or it should force multipart posts when this > information is present. -- 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] [Reopened] (SOLR-4358) SolrJ, by preventing multi-part post, loses key information about file name that Tika needs
[ https://issues.apache.org/jira/browse/SOLR-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man reopened SOLR-4358: As noted by Uwe on the dev list, the changes committed for this issue seem ot have caused various test failures, as well as sending ChaosMonkeySafeLeader into an infinite loop(?!) Re-opening to investigate - likely need to roll back these changes if we can't get to the bottom of things right away > SolrJ, by preventing multi-part post, loses key information about file name > that Tika needs > --- > > Key: SOLR-4358 > URL: https://issues.apache.org/jira/browse/SOLR-4358 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Karl Wright >Assignee: Ryan McKinley > Attachments: SOLR-4358.patch, SOLR-4358.patch > > > SolrJ accepts a ContentStream, which has a name field. Within > HttpSolrServer.java, if SolrJ makes the decision to use multipart posts, this > filename is transmitted as part of the form boundary information. However, > if SolrJ chooses not to use multipart post, the filename information is lost. > This information is used by SolrCell (Tika) to make decisions about content > extraction, so it is very important that it makes it into Solr in one way or > another. Either SolrJ should set appropriate equivalent headers to send the > filename automatically, or it should force multipart posts when this > information is present. -- 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-4487) SolrException usage in solrj client code can't handle all possible http error codes returned by servers -- example "413 Request Entity Too Large"
[ https://issues.apache.org/jira/browse/SOLR-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-4487: --- Fix Version/s: 4.3 > SolrException usage in solrj client code can't handle all possible http error > codes returned by servers -- example "413 Request Entity Too Large" > - > > Key: SOLR-4487 > URL: https://issues.apache.org/jira/browse/SOLR-4487 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 4.0 >Reporter: Alexander Dietrich >Assignee: Hoss Man > Fix For: 4.3 > > Attachments: SOLR-4487.patch > > > Solr responds to excessively large queries with a 413 status code, but > HttpSolrServer.request() loses this information when it tries to look up the > code in SolrException.ErrorCode, resulting in a status code 0 in the thrown > exception. > Being able to see this status code would be helpful. -- 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-4487) SolrException usage in solrj client code can't handle all possible http error codes returned by servers -- example "413 Request Entity Too Large"
[ https://issues.apache.org/jira/browse/SOLR-4487?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Hoss Man updated SOLR-4487: --- Attachment: SOLR-4487.patch Patch with fix and tests. holding off on committing just yet because some other HttpSolrServer changes that just got committed seem to have broken bunch of tests, waiting for things to return to stead state. > SolrException usage in solrj client code can't handle all possible http error > codes returned by servers -- example "413 Request Entity Too Large" > - > > Key: SOLR-4487 > URL: https://issues.apache.org/jira/browse/SOLR-4487 > Project: Solr > Issue Type: Improvement > Components: clients - java >Affects Versions: 4.0 >Reporter: Alexander Dietrich >Assignee: Hoss Man > Attachments: SOLR-4487.patch > > > Solr responds to excessively large queries with a 413 status code, but > HttpSolrServer.request() loses this information when it tries to look up the > code in SolrException.ErrorCode, resulting in a status code 0 in the thrown > exception. > Being able to see this status code would be helpful. -- 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-3251) dynamically add field to schema
[
https://issues.apache.org/jira/browse/SOLR-3251?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633484#comment-13633484
]
Steve Rowe commented on SOLR-3251:
--
bq. I admit I don't understand the catch-22, but for these factories to return
null I think is a very serious problem.
I agree - I'll fix it. In the SolrCore constructor, the Sim factory's
{{getSimilarity()}} is called before {{inform()}} is called on registered
SolrCoreAware objects, so I'll call the Sim and Codec factories' {{inform()}}
methods as soon as they're bound to the core, if they're SolrCoreAware.
> dynamically add field to schema
> ---
>
> Key: SOLR-3251
> URL: https://issues.apache.org/jira/browse/SOLR-3251
> Project: Solr
> Issue Type: New Feature
>Reporter: Yonik Seeley
>Assignee: Steve Rowe
> Fix For: 4.3
>
> Attachments: SOLR-3251.patch, SOLR-3251.patch, SOLR-3251.patch,
> SOLR-3251.patch, SOLR-3251.patch
>
>
> One related piece of functionality needed for SOLR-3250 is the ability to
> dynamically add a field to the schema.
--
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-4937) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/LUCENE-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler resolved LUCENE-4937. --- Resolution: Fixed I committed to 4.x branch and merged the tests to trunk, the other changes merged successfully as identical code now. > sort order different in branch_4x than trunk > > > Key: LUCENE-4937 > URL: https://issues.apache.org/jira/browse/LUCENE-4937 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Assignee: Uwe Schindler > Fix For: 4.3 > > Attachments: LUCENE-4937.patch, LUCENE-4937.patch, > LUCENE-4937_test.patch, SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4937) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/LUCENE-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633467#comment-13633467 ] Uwe Schindler commented on LUCENE-4937: --- Looking forward to see you in Berlin! > sort order different in branch_4x than trunk > > > Key: LUCENE-4937 > URL: https://issues.apache.org/jira/browse/LUCENE-4937 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Assignee: Uwe Schindler > Fix For: 4.3 > > Attachments: LUCENE-4937.patch, LUCENE-4937.patch, > LUCENE-4937_test.patch, SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4937) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/LUCENE-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633464#comment-13633464 ] Robert Muir commented on LUCENE-4937: - Thanks Uwe: now i owe some beer! > sort order different in branch_4x than trunk > > > Key: LUCENE-4937 > URL: https://issues.apache.org/jira/browse/LUCENE-4937 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Assignee: Uwe Schindler > Fix For: 4.3 > > Attachments: LUCENE-4937.patch, LUCENE-4937.patch, > LUCENE-4937_test.patch, SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4937) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/LUCENE-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4937: -- Attachment: LUCENE-4937.patch Patch including all tests on this issue. I will commit this to 4.x and then merge to trunk (the tests) > sort order different in branch_4x than trunk > > > Key: LUCENE-4937 > URL: https://issues.apache.org/jira/browse/LUCENE-4937 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Assignee: Uwe Schindler > Fix For: 4.3 > > Attachments: LUCENE-4937.patch, LUCENE-4937.patch, > LUCENE-4937_test.patch, SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4937) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/LUCENE-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4937: -- Fix Version/s: 4.3 > sort order different in branch_4x than trunk > > > Key: LUCENE-4937 > URL: https://issues.apache.org/jira/browse/LUCENE-4937 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Assignee: Uwe Schindler > Fix For: 4.3 > > Attachments: LUCENE-4937.patch, LUCENE-4937_test.patch, > SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4935) CustomScoreQuery has broken boosting
[ https://issues.apache.org/jira/browse/LUCENE-4935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633441#comment-13633441 ] Michael McCandless commented on LUCENE-4935: +1 for the 2nd approach. > CustomScoreQuery has broken boosting > > > Key: LUCENE-4935 > URL: https://issues.apache.org/jira/browse/LUCENE-4935 > Project: Lucene - Core > Issue Type: Bug > Components: core/query/scoring >Reporter: Robert Muir > Attachments: LUCENE-4935.patch, LUCENE-4935.patch > > > CustomScoreQuery wrongly applies boost^2 instead of boost. > It wrongly incorporates its boost into the normalization factor passed down > to subquery (like booleanquery does) and *also* multiplies it directly in its > scorer. > The only reason the test passes today is because it compares raw score > magnitudes when querynorm is on, which normalizes this away. > Changing the test to use newSearcher() demonstrates the brokenness. -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (LUCENE-4937) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/LUCENE-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler reassigned LUCENE-4937: - Assignee: Uwe Schindler > sort order different in branch_4x than trunk > > > Key: LUCENE-4937 > URL: https://issues.apache.org/jira/browse/LUCENE-4937 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir >Assignee: Uwe Schindler > Attachments: LUCENE-4937.patch, LUCENE-4937_test.patch, > SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4937) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/LUCENE-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler updated LUCENE-4937: -- Attachment: LUCENE-4937.patch Here the patch, what I did: - I merged Adriens patch for from trunk to 4.x - I reverted all Java 7 Integer.compare(),... > sort order different in branch_4x than trunk > > > Key: LUCENE-4937 > URL: https://issues.apache.org/jira/browse/LUCENE-4937 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-4937.patch, LUCENE-4937_test.patch, > SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4937) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/LUCENE-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated LUCENE-4937: Attachment: LUCENE-4937_test.patch here's some tests for lucene (fieldcache and docvalues, both fail in 4.x) > sort order different in branch_4x than trunk > > > Key: LUCENE-4937 > URL: https://issues.apache.org/jira/browse/LUCENE-4937 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: LUCENE-4937.patch, LUCENE-4937_test.patch, > SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4722) Highlighter which generates a list of query term position(s) for each item in a list of documents, or returns null if highlighting is disabled.
[ https://issues.apache.org/jira/browse/SOLR-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633307#comment-13633307 ] Tricia Jenkins edited comment on SOLR-4722 at 4/16/13 9:52 PM: --- Stems from the same usecase as SOLR-380. was (Author: pgwillia): Stems from the same usecase. > Highlighter which generates a list of query term position(s) for each item in > a list of documents, or returns null if highlighting is disabled. > --- > > Key: SOLR-4722 > URL: https://issues.apache.org/jira/browse/SOLR-4722 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 4.3, 5.0 >Reporter: Tricia Jenkins >Priority: Minor > Attachments: SOLR-4722.patch, solr-positionshighlighter.jar > > > As an alternative to returning snippets, this highlighter provides the (term) > position for query matches. One usecase for this is to reconcile the term > position from the Solr index with 'word' coordinates provided by an OCR > process. In this way we are able to 'highlight' an image, like a page from a > book or an article from a newspaper, in the locations that match the user's > query. > This is based on the FastVectorHighlighter and requires that termVectors, > termOffsets and termPositions be stored. -- 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-4722) Highlighter which generates a list of query term position(s) for each item in a list of documents, or returns null if highlighting is disabled.
[
https://issues.apache.org/jira/browse/SOLR-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633426#comment-13633426
]
Tricia Jenkins edited comment on SOLR-4722 at 4/16/13 9:52 PM:
---
Solr plug-in jar compiled against 4.1.0. Place this into your
solr.home/collection/lib directory and configure conf/solrconfig.xml
{code:xml}
{code}
to use.
was (Author: pgwillia):
Solr plug-in jar compiled against 4.1.0. Place this into your
solr.home/collection/lib and configure conf/solrconfig.xml
{code:xml}
{code}
directory to use.
> Highlighter which generates a list of query term position(s) for each item in
> a list of documents, or returns null if highlighting is disabled.
> ---
>
> Key: SOLR-4722
> URL: https://issues.apache.org/jira/browse/SOLR-4722
> Project: Solr
> Issue Type: New Feature
> Components: highlighter
>Affects Versions: 4.3, 5.0
>Reporter: Tricia Jenkins
>Priority: Minor
> Attachments: SOLR-4722.patch, solr-positionshighlighter.jar
>
>
> As an alternative to returning snippets, this highlighter provides the (term)
> position for query matches. One usecase for this is to reconcile the term
> position from the Solr index with 'word' coordinates provided by an OCR
> process. In this way we are able to 'highlight' an image, like a page from a
> book or an article from a newspaper, in the locations that match the user's
> query.
> This is based on the FastVectorHighlighter and requires that termVectors,
> termOffsets and termPositions be stored.
--
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-4722) Highlighter which generates a list of query term position(s) for each item in a list of documents, or returns null if highlighting is disabled.
[ https://issues.apache.org/jira/browse/SOLR-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633305#comment-13633305 ] Tricia Jenkins edited comment on SOLR-4722 at 4/16/13 9:51 PM: --- Loosely related to SOLR-1954 and SOLR-1397. SOLR-1954 is looking at exposing offsets and score in addition to snippets. SOLR-1397 is looking to highlight external fields, say from a database, with a Solr highlighter (and analysis). was (Author: pgwillia): Loosely related to SOLR-1954 and SOLR-1397. SOLR-1954 is looking at exposing offsets and score in addition to snippets. SOlR-1397 is looking to highlight external fields, say from a database, with a Solr highlighter (and analysis). > Highlighter which generates a list of query term position(s) for each item in > a list of documents, or returns null if highlighting is disabled. > --- > > Key: SOLR-4722 > URL: https://issues.apache.org/jira/browse/SOLR-4722 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 4.3, 5.0 >Reporter: Tricia Jenkins >Priority: Minor > Attachments: SOLR-4722.patch, solr-positionshighlighter.jar > > > As an alternative to returning snippets, this highlighter provides the (term) > position for query matches. One usecase for this is to reconcile the term > position from the Solr index with 'word' coordinates provided by an OCR > process. In this way we are able to 'highlight' an image, like a page from a > book or an article from a newspaper, in the locations that match the user's > query. > This is based on the FastVectorHighlighter and requires that termVectors, > termOffsets and termPositions be stored. -- 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-4722) Highlighter which generates a list of query term position(s) for each item in a list of documents, or returns null if highlighting is disabled.
[
https://issues.apache.org/jira/browse/SOLR-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Tricia Jenkins updated SOLR-4722:
-
Attachment: solr-positionshighlighter.jar
Solr plug-in jar compiled against 4.1.0. Place this into your
solr.home/collection/lib and configure conf/solrconfig.xml
{code:xml}
{code}
directory to use.
> Highlighter which generates a list of query term position(s) for each item in
> a list of documents, or returns null if highlighting is disabled.
> ---
>
> Key: SOLR-4722
> URL: https://issues.apache.org/jira/browse/SOLR-4722
> Project: Solr
> Issue Type: New Feature
> Components: highlighter
>Affects Versions: 4.3, 5.0
>Reporter: Tricia Jenkins
>Priority: Minor
> Attachments: SOLR-4722.patch, solr-positionshighlighter.jar
>
>
> As an alternative to returning snippets, this highlighter provides the (term)
> position for query matches. One usecase for this is to reconcile the term
> position from the Solr index with 'word' coordinates provided by an OCR
> process. In this way we are able to 'highlight' an image, like a page from a
> book or an article from a newspaper, in the locations that match the user's
> query.
> This is based on the FastVectorHighlighter and requires that termVectors,
> termOffsets and termPositions be stored.
--
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-4470) Support for basic http auth in internal solr requests
[ https://issues.apache.org/jira/browse/SOLR-4470?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633415#comment-13633415 ] Alexey Serba commented on SOLR-4470: bq. Acording to HTTP-URL syntax, you can give the basic auth params using http://user:password@host:port/. As Solr is using Commons-Httpsclient for connections, wouldnt this work automatically if you configure the node's HTTP adress using this syntax? +1, I like this solution for *generic* http basic auth support in Solr/Cloud bq. Besides that we plan to (later) go for HTTPS in order to encrypt the clear text ... username/password in the requests, and I believe that the URL itself is not being encrypted in HTTPS. I don't think this is the case. And "user:password" part won't be transmitted in a url, but will be parsed by httpclient and submitted as a proper HTTP headers. > Support for basic http auth in internal solr requests > - > > Key: SOLR-4470 > URL: https://issues.apache.org/jira/browse/SOLR-4470 > Project: Solr > Issue Type: New Feature > Components: clients - java, multicore, replication (java), SolrCloud >Affects Versions: 4.0 >Reporter: Per Steffensen > Labels: authentication, https, solrclient, solrcloud, ssl > Fix For: 4.3 > > Attachments: SOLR-4470_branch_4x_r1452629.patch, > SOLR-4470_branch_4x_r1452629.patch, SOLR-4470_branch_4x_r145.patch, > SOLR-4470.patch > > > We want to protect any HTTP-resource (url). We want to require credentials no > matter what kind of HTTP-request you make to a Solr-node. > It can faily easy be acheived as described on > http://wiki.apache.org/solr/SolrSecurity. This problem is that Solr-nodes > also make "internal" request to other Solr-nodes, and for it to work > credentials need to be provided here also. > Ideally we would like to "forward" credentials from a particular request to > all the "internal" sub-requests it triggers. E.g. for search and update > request. > But there are also "internal" requests > * that only indirectly/asynchronously triggered from "outside" requests (e.g. > shard creation/deletion/etc based on calls to the "Collection API") > * that do not in any way have relation to an "outside" "super"-request (e.g. > replica synching stuff) > We would like to aim at a solution where "original" credentials are > "forwarded" when a request directly/synchronously trigger a subrequest, and > fallback to a configured "internal credentials" for the > asynchronous/non-rooted requests. > In our solution we would aim at only supporting basic http auth, but we would > like to make a "framework" around it, so that not to much refactoring is > needed if you later want to make support for other kinds of auth (e.g. digest) > We will work at a solution but create this JIRA issue early in order to get > input/comments from the community as early as possible. -- 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] [Moved] (LUCENE-4937) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/LUCENE-4937?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Uwe Schindler moved SOLR-4723 to LUCENE-4937: - Lucene Fields: New Key: LUCENE-4937 (was: SOLR-4723) Project: Lucene - Core (was: Solr) > sort order different in branch_4x than trunk > > > Key: LUCENE-4937 > URL: https://issues.apache.org/jira/browse/LUCENE-4937 > Project: Lucene - Core > Issue Type: Bug >Reporter: Robert Muir > Attachments: SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4722) Highlighter which generates a list of query term position(s) for each item in a list of documents, or returns null if highlighting is disabled.
[ https://issues.apache.org/jira/browse/SOLR-4722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Tricia Jenkins updated SOLR-4722: - Attachment: SOLR-4722.patch This patch applies against trunk and includes a unit test. 4.x would require a slight modification because StoredDocument was introduced more recently. Formerly org.apache.solr.search.SolrIndexSearcher.doc(...) returned Document. > Highlighter which generates a list of query term position(s) for each item in > a list of documents, or returns null if highlighting is disabled. > --- > > Key: SOLR-4722 > URL: https://issues.apache.org/jira/browse/SOLR-4722 > Project: Solr > Issue Type: New Feature > Components: highlighter >Affects Versions: 4.3, 5.0 >Reporter: Tricia Jenkins >Priority: Minor > Attachments: SOLR-4722.patch > > > As an alternative to returning snippets, this highlighter provides the (term) > position for query matches. One usecase for this is to reconcile the term > position from the Solr index with 'word' coordinates provided by an OCR > process. In this way we are able to 'highlight' an image, like a page from a > book or an article from a newspaper, in the locations that match the user's > query. > This is based on the FastVectorHighlighter and requires that termVectors, > termOffsets and termPositions be stored. -- 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-4933) SweetSpotSimilarity doesnt override tf(float)
[ https://issues.apache.org/jira/browse/LUCENE-4933?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633392#comment-13633392 ] Michael McCandless commented on LUCENE-4933: +1 to remove the confusing double tf ... it seems incredibly trappy. > SweetSpotSimilarity doesnt override tf(float) > - > > Key: LUCENE-4933 > URL: https://issues.apache.org/jira/browse/LUCENE-4933 > Project: Lucene - Core > Issue Type: Bug > Components: core/query/scoring >Affects Versions: 2.0.0 >Reporter: Robert Muir > Attachments: LUCENE-4933.patch > > > This means its scoring is not really right: it only applies to term queries > and exact phrase queries, but not e.g. sloppy phrase queries and spans. > As far as I can tell, its had this bug all along. -- 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-4723) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/SOLR-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633390#comment-13633390 ] Uwe Schindler commented on SOLR-4723: - See my comment, we can fix it. The static compare methods are available in since Java 1.4. > sort order different in branch_4x than trunk > > > Key: SOLR-4723 > URL: https://issues.apache.org/jira/browse/SOLR-4723 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir > Attachments: SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4723) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/SOLR-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633388#comment-13633388 ] Robert Muir commented on SOLR-4723: --- A documentation fix is fine by me... I just found it surprising since i couldnt reproduce from trunk. > sort order different in branch_4x than trunk > > > Key: SOLR-4723 > URL: https://issues.apache.org/jira/browse/SOLR-4723 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir > Attachments: SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4723) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/SOLR-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633387#comment-13633387 ] Uwe Schindler commented on SOLR-4723: - We can fix the bug also in Java 6, because Float.compare(float,float) and Double.compare(double,double) are there since Java 1.4. It is only integer's compare which iss missing. So we should really use the correct Double/Float functions: - [http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Double.html#compare(double, double)] - [http://docs.oracle.com/javase/1.4.2/docs/api/java/lang/Float.html#compare(float, float)] > sort order different in branch_4x than trunk > > > Key: SOLR-4723 > URL: https://issues.apache.org/jira/browse/SOLR-4723 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir > Attachments: SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4723) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/SOLR-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633382#comment-13633382 ] Uwe Schindler commented on SOLR-4723: - The pre-trunk code is wrong for comparing doubles/floats, as v1 > v2 does not work with +/-0 (its identical for operators <, >, ==). In Java 7, Double/Float.compare() compares the bits. The easiest way to solve the problem is using NumericUtils.doubleToSortableLong/floatToSortableInt and then compare the long/int. NumericUtils converts the floating point value to an integer, with fixing the sign to be comparable like a int (see javadocs). I think this is a corner case (like the crazy bugs if the score is NaN), so maybe we should only fix in 5.0 but leave 4.x and all previous lucene versions as they are. > sort order different in branch_4x than trunk > > > Key: SOLR-4723 > URL: https://issues.apache.org/jira/browse/SOLR-4723 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir > Attachments: SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633362#comment-13633362 ] Mark Miller edited comment on SOLR-4718 at 4/16/13 9:05 PM: bq. This has nothing to do with local support and everything to do with where on ZK the solr.xml file is. That should not be configurable. bq. it should be possible to just install a stock solr with no modifications on a node, fire it up without having any a-priori files and be done with it. That is possible - but you have to specify zkhost as a sys prop on the cmd line then. As I've said, the solr.properties file is optional - it will get there because the user decides to create it. I think all of this is pretty simple - I'm happy to implement it. was (Author: markrmil...@gmail.com): bq. This has nothing to do with local support and everything to do with where on ZK the solr.xml file is. That should not be configurable. bq. it should be possible to just install a stock solr with no modifications on a node, fire it up without having any a-priori files and be done with it. That is possible - but you have to specify zkhost on as sys prop on the cmd line then. As I've said, the solr.properties file is optional - it will get there because the user decides to create it. I think all of this is pretty simple - I'm happy to implement it. > 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 > > 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: > > > zkurl > whatever > > >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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633362#comment-13633362 ] Mark Miller commented on SOLR-4718: --- bq. This has nothing to do with local support and everything to do with where on ZK the solr.xml file is. That should not be configurable. bq. it should be possible to just install a stock solr with no modifications on a node, fire it up without having any a-priori files and be done with it. That is possible - but you have to specify zkhost on as sys prop on the cmd line then. As I've said, the solr.properties file is optional - it will get there because the user decides to create it. I think all of this is pretty simple - I'm happy to implement it. > 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 > > 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: > > > zkurl > whatever > > >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-4438) Developer Curb Appeal: Cloud Admin UI: Need legend, and maybe mouse-over
[ https://issues.apache.org/jira/browse/SOLR-4438?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633355#comment-13633355 ] Mark Bennett commented on SOLR-4438: Will come up with specific info list, and then I'll split the bug as well. > Developer Curb Appeal: Cloud Admin UI: Need legend, and maybe mouse-over > > > Key: SOLR-4438 > URL: https://issues.apache.org/jira/browse/SOLR-4438 > Project: Solr > Issue Type: Improvement > Components: SolrCloud >Affects Versions: 4.1 >Reporter: Mark Bennett > Fix For: 4.3 > > > It's nice that we display a cloud view showing a graphical representation of > the cluster. > However, it'd be nice if we included a Legend to explain what the colors mean. > Some reasons the current system might not be as obvious as you'd think: > * The colors don't look exactly Green, Yellow, Red, and Gray on some monitors > * I'm told that the green=good, red=bad, etc isn't universal in all countries. > * Some people can't see the colors. Of course a color code legend won't be > of much help to a color blind person. Ideally we might also put a textual > status in parenthesis to the right of the IP address. > Additionally it'd be nice to have some type of mouse-over with a bit more > summary info, if known. (although that doesn't help tablet users). > We could consider changing the click behavior to show the mouse-over dialog > box, and then let them click in there to open a new window with that other > node's details. > It would also be nice to indicate which node we're currently on. -- 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-4723) sort order different in branch_4x than trunk
[
https://issues.apache.org/jira/browse/SOLR-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633352#comment-13633352
]
Robert Muir commented on SOLR-4723:
---
It might be that trunk uses Double.compare (from a java7 commit?) and branch_4x
does this:
{code}
if (v1 > v2) {
return 1;
} else if (v1 < v2) {
return -1;
} else {
return 0;
}
{code}
If so this is not right, because NumericUtils documents it is consistent with
Double.compareTo and Float.compareTo, so something needs to be fixed.
> sort order different in branch_4x than trunk
>
>
> Key: SOLR-4723
> URL: https://issues.apache.org/jira/browse/SOLR-4723
> Project: Solr
> Issue Type: Bug
>Reporter: Robert Muir
> Attachments: SOLR-4723_test.patch
>
>
> I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x,
> but works correctly in trunk :)
--
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-4718) Allow solr.xml to be stored in zookeeper
[
https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633350#comment-13633350
]
Erick Erickson commented on SOLR-4718:
--
[~elyograg]
Note the structure here. Solr.xml has something like
${hostPort:44}
but solr.properties just has
hostPort=55
so solr.properties _always_ overrides solr.xml. If you don't put the ${} syntax
in, you don't get the substitution.
[~wunder]
about syntax errors. How about blow up, first time, every time. As in refuse to
start Solr? This will still be at startup. Fail early, fail often.
[~markrmil...@gmail.com]
bq: zkSolrXmlPath ... -1 on this guy.
This has nothing to do with local support and everything to do with where on ZK
the solr.xml file is. I don't have strong feelings either way, but if we want
to support multiple wars in the same JVM that have different solr.xmls seems
like we need a way to distinguish where they are stored on ZK. That said, on
the KISS principle I can get behind "OK, define a generic solr.xml, it always
lives in the root on ZK and put your changes in the solr.properties file that
exists locally". We can always add this later iff a good use-case comes up
requiring it.
All:
I'm having something of a problem with solr.properties only being disk-based
(even though I'd also like it to be). How do we get it there in the first
place? Here's what I'm thinking; it should be possible to just install a stock
solr with _no_ modifications on a node, fire it up _without_ having any
a-priori files and be done with it. If we require the "correct" solr.properties
file to be there why don't we just require the correct solr.xml and not bother
with a properties file? (I'm over-stating the case here, but)
I want to say "java -DzkHost=blah -jar start.jar" and be done with it. I'm
probably missing something, but any time we require local files (in this case
solr.properties), whether an installation uses any of the auto-config tools or
not, it seems like the same problem as requiring the "right" version of
solr.xml.
Or is this just one of those cases where I'm over-thinking it and I should just
get over it and assume anyone who wants all this flexibility is also capable of
getting the right solr.properties file in the right place?
> 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
>
> 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:
>
>
> zkurl
> whatever
>
>
>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.
[jira] [Commented] (SOLR-4723) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/SOLR-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1366#comment-1366 ] Robert Muir commented on SOLR-4723: --- and this might be a lucene bug. i just pulled out a lot of hair trying to track down WTF so i need a break. > sort order different in branch_4x than trunk > > > Key: SOLR-4723 > URL: https://issues.apache.org/jira/browse/SOLR-4723 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir > Attachments: SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4723) sort order different in branch_4x than trunk
[ https://issues.apache.org/jira/browse/SOLR-4723?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Robert Muir updated SOLR-4723: -- Attachment: SOLR-4723_test.patch here's my test. > sort order different in branch_4x than trunk > > > Key: SOLR-4723 > URL: https://issues.apache.org/jira/browse/SOLR-4723 > Project: Solr > Issue Type: Bug >Reporter: Robert Muir > Attachments: SOLR-4723_test.patch > > > I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, > but works correctly in trunk :) -- 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-4723) sort order different in branch_4x than trunk
Robert Muir created SOLR-4723: - Summary: sort order different in branch_4x than trunk Key: SOLR-4723 URL: https://issues.apache.org/jira/browse/SOLR-4723 Project: Solr Issue Type: Bug Reporter: Robert Muir Attachments: SOLR-4723_test.patch I will buy a beer to whoever figures out why +0 sorts before -0 in branch_4x, but works correctly in trunk :) -- 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-2082) Performance improvement for merging posting lists
[ https://issues.apache.org/jira/browse/LUCENE-2082?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=1363#comment-1363 ] Aleksandra Wozniak commented on LUCENE-2082: Is anyone actively working on this improvement? If not, I was wondering if I could contribute -- I'm a graduate CS student and for my final project I'm investigating ways to optimize merging and index creation time of text indices. During my research I recently came across this ticket and I thought that I'd like to implement this idea. I took a first look at the source code -- it seems that the codebase changed significantly since the time this issue was created. From what I found in the documentation (http://lucene.apache.org/core/4_0_0/MIGRATE.html), many classes mentioned here changed their names and API. Could you please update the description above or comment on what parts of it are no longer valid? > Performance improvement for merging posting lists > - > > Key: LUCENE-2082 > URL: https://issues.apache.org/jira/browse/LUCENE-2082 > Project: Lucene - Core > Issue Type: Improvement > Components: core/index >Reporter: Michael Busch >Priority: Minor > Labels: gsoc2013 > Fix For: 4.3 > > > A while ago I had an idea about how to improve the merge performance > for posting lists. This is currently by far the most expensive part of > segment merging due to all the VInt de-/encoding. Not sure if an idea > for improving this was already mentioned in the past? > So the basic idea is it to perform a raw copy of as much posting data > as possible. The reason why this is difficult is that we have to > remove deleted documents. But often the fraction of deleted docs in a > segment is rather low (<10%?), so it's likely that there are quite > long consecutive sections without any deletions. > To find these sections we could use the skip lists. Basically at any > point during the merge we would find the skip entry before the next > deleted doc. All entries to this point can be copied without > de-/encoding of the VInts. Then for the section that has deleted docs > we perform the "normal" way of merging to remove the deletes. Then we > check again with the skip lists if we can raw copy the next section. > To make this work there are a few different necessary changes: > 1) Currently the multilevel skiplist reader/writer can only deal with > fixed-size > skips (16 on the lowest level). It would be an easy change to allow > variable-size skips, but then the MultiLevelSkipListReader can't > return numSkippedDocs anymore, which SegmentTermDocs needs -> change 2) > 2) Store the last docID in which a term occurred in the term > dictionary. This would also be beneficial for other use cases. By > doing that the SegmentTermDocs#next(), #read() and #skipTo() know when > the end of the postinglist is reached. Currently they have to track > the df, which is why after a skip it's important to take the > numSkippedDocs into account. > 3) Change the merging algorithm according to my description above. It's > important to create a new skiplist entry at the beginning of every > block that is copied in raw mode, because its next skip entry's values > are deltas from the beginning of the block. Also the very first posting, and > that one only, needs to be decoded/encoded to make sure that the > payload length is explicitly written (i.e. must not depend on the > previous length). Also such a skip entry has to be created at the > beginning of each source segment's posting list. With change 2) we don't > have to worry about the positions of the skip entries. And having a few > extra skip entries in merged segments won't hurt much. > If a segment has no deletions at all this will avoid any > decoding/encoding of VInts (best case). I think it will also work > great for segments with a rather low amount of deletions. We should > probably then have a threshold: if the number of deletes exceeds this > threshold we should fall back to old style merging. > I haven't implemented any of this, so there might be complications I > haven't thought about. Please let me know if you can think of reasons > why this wouldn't work or if you think more changes are necessary. > I will probably not have time to work on this soon, but I wanted to > open this issue to not forget about it :). Anyone should feel free to > take this! > Btw: I think the flex-indexing branch would be a great place to try this > out as a new codec. This would also be good to figure out what APIs > are needed to make merging fully flexible as well. -- 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] [Resolved] (SOLR-3980) Incorporate lazily-loaded cores into core listings for clients
[ https://issues.apache.org/jira/browse/SOLR-3980?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Erick Erickson resolved SOLR-3980. -- Resolution: Fixed Fix Version/s: 5.0 This has been fixed for a while, see SOLR-1533 for instance. > Incorporate lazily-loaded cores into core listings for clients > -- > > Key: SOLR-3980 > URL: https://issues.apache.org/jira/browse/SOLR-3980 > Project: Solr > Issue Type: Improvement > Components: multicore, web gui >Affects Versions: 4.1 >Reporter: Erick Erickson >Assignee: Erick Erickson >Priority: Minor > Fix For: 4.3, 5.0 > > > Part of SOLR-1293 (supporting lots of cores) will require we do something to > allow clients (particularly the admin GUI) to get a full list of all possible > cores, whether they've been loaded or not. -- 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-4722) Highlighter which generates a list of query term position(s) for each item in a list of documents, or returns null if highlighting is disabled.
Tricia Jenkins created SOLR-4722: Summary: Highlighter which generates a list of query term position(s) for each item in a list of documents, or returns null if highlighting is disabled. Key: SOLR-4722 URL: https://issues.apache.org/jira/browse/SOLR-4722 Project: Solr Issue Type: New Feature Components: highlighter Affects Versions: 4.3, 5.0 Reporter: Tricia Jenkins Priority: Minor As an alternative to returning snippets, this highlighter provides the (term) position for query matches. One usecase for this is to reconcile the term position from the Solr index with 'word' coordinates provided by an OCR process. In this way we are able to 'highlight' an image, like a page from a book or an article from a newspaper, in the locations that match the user's query. This is based on the FastVectorHighlighter and requires that termVectors, termOffsets and termPositions be stored. -- 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-4717) SimpleFacets should respect localParams
[
https://issues.apache.org/jira/browse/SOLR-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-4717:
Fix Version/s: 5.0
4.3
> SimpleFacets should respect localParams
> ---
>
> Key: SOLR-4717
> URL: https://issues.apache.org/jira/browse/SOLR-4717
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Fix For: 4.3, 5.0
>
> Attachments: SOLR-4717-FacetLocalParams.patch
>
>
> In trying to implement http://wiki.apache.org/solr/HierarchicalFaceting I
> found the need to send multiple prefix facets in the same request on the same
> field.
> Currently facet params will parse the localParams, but only use them to pick
> out a name. We can easily modify things to let localParams override global
> ones. For example:
> {code}
> &{!key=level3 facet.prefix=3/path/to/folder}path
> &{!key=level2 facet.prefix=2/path/to}path
> &{!key=level1 facet.prefix=1/path}path
> {code}
> This can easily be supported if we use:
> {code:java}
> params = SolrParams.wrapDefaults(localParams, orig);
> {code}
> when local params exist
> --
> We have come a long way from *simple* facets!
--
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-4358) SolrJ, by preventing multi-part post, loses key information about file name that Tika needs
[ https://issues.apache.org/jira/browse/SOLR-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-4358. - Resolution: Fixed added to trunk and 4x > SolrJ, by preventing multi-part post, loses key information about file name > that Tika needs > --- > > Key: SOLR-4358 > URL: https://issues.apache.org/jira/browse/SOLR-4358 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Karl Wright >Assignee: Ryan McKinley > Attachments: SOLR-4358.patch, SOLR-4358.patch > > > SolrJ accepts a ContentStream, which has a name field. Within > HttpSolrServer.java, if SolrJ makes the decision to use multipart posts, this > filename is transmitted as part of the form boundary information. However, > if SolrJ chooses not to use multipart post, the filename information is lost. > This information is used by SolrCell (Tika) to make decisions about content > extraction, so it is very important that it makes it into Solr in one way or > another. Either SolrJ should set appropriate equivalent headers to send the > filename automatically, or it should force multipart posts when this > information is present. -- 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-4721) Admin UI - Error Handling on initial load
Stefan Matheis (steffkes) created SOLR-4721:
---
Summary: Admin UI - Error Handling on initial load
Key: SOLR-4721
URL: https://issues.apache.org/jira/browse/SOLR-4721
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Fix For: 4.3
Seen this this Week on IRC, at least once. The UI was not completely loaded
(only displayed the initial "Loading ..." forever) because {{/admin/cores}}
doesn't respond with valid information.
don't remember of the actual error in this case, but we should handle this
scenario better than we do right now.
We'll see what information we can get from the request and how we can display
it. at least it should block the whole UI somehow that make it clear that
something goes completely wrong - there is no way around, /admin/cores is the
very first request we make to gather initial informations ..
--
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-4720) Admin UI - Empty List of Iterations on Slave
Stefan Matheis (steffkes) created SOLR-4720: --- Summary: Admin UI - Empty List of Iterations on Slave Key: SOLR-4720 URL: https://issues.apache.org/jira/browse/SOLR-4720 Project: Solr Issue Type: Improvement Components: web gui Reporter: Stefan Matheis (steffkes) Assignee: Stefan Matheis (steffkes) Priority: Trivial Fix For: 4.3 If you start your slave and have a look at the Replication Page, the list of iterations may be empty - but it's not cristal clear if it's a bug (iteration happend, info available but not shown) or just a matter of fact, that there has nothing happend. -- 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-4719) Admin UI - Default to wt=json on Query-Screen
Stefan Matheis (steffkes) created SOLR-4719:
---
Summary: Admin UI - Default to wt=json on Query-Screen
Key: SOLR-4719
URL: https://issues.apache.org/jira/browse/SOLR-4719
Project: Solr
Issue Type: Improvement
Components: web gui
Reporter: Stefan Matheis (steffkes)
Assignee: Stefan Matheis (steffkes)
Priority: Minor
Fix For: 4.3
I didn't really notice that we're still using {{wt=xml}} as default on the
Query-Screen .. i suggest we change that to {{wt=json}} .. it's 2013 =)
Syntax-Highlight would still work, even if one tries the example-configuration
where the content-type is overwritten with text/plain, since it's based on the
selection on the left side :)
Any objections?
--
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-4661) Index Version & Gen look out of sync in replication UI when master searcher uses older commit then what is replicatable
[
https://issues.apache.org/jira/browse/SOLR-4661?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Stefan Matheis (steffkes) updated SOLR-4661:
Attachment: SOLR-4661.patch
Updated Patch, includes changes from the replication page for the dashboard
(were the same information also appear).
Missing Information/Empty Versions are shown as '-' so it should be clear for
everyone
> Index Version & Gen look out of sync in replication UI when master searcher
> uses older commit then what is replicatable
> ---
>
> Key: SOLR-4661
> URL: https://issues.apache.org/jira/browse/SOLR-4661
> Project: Solr
> Issue Type: Bug
> Components: replication (java), web gui
>Affects Versions: 4.2
> Environment: Solr 4.2 on Linux with JBoss 7.1.1, JDK 1.7
>Reporter: Aditya
> Labels: gui, replication, web
> Attachments: hoss_test.zip, IndexVersionSyncIssue.jpg,
> SOLR-4661.patch, SOLR-4661.patch, SOLR-4661.patch
>
>
> the ReplicationHandler (and the replication admin UI screen) report the index
> version & gen for the master based on what commit point is currently open for
> searching -- but this is not necessarily the most recent commit point
> available for replication.
> Thus, it can appear that a slave has "gotten ahead" of the master, if there
> are "empty commits" (because of reader reopening shotcuts) or commits using
> openSearcher=false.
> We need to add additional data to help make it clear there is no actual
> problem in this sitation.
> Summary of original bug report..
> {panel}
> Index and Gen number on Slave is higher than master.
> If you apply commit on master with no pending docs then the commit time stamp
> and gen is incremented. When Slaves polls master for replication it see the
> index version difference and starts replicating but all files are skipped.
> On Admin UI (on Slaves) the version number displayed for master is old where
> as for slave is the latest which is higher than master.
> Below is the response from master (/replication?command=details) where i see
> two different Version an Gen numbers. This creates confusion of having
> version out of sync, though its not.
> ...
> {panel}
--
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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633201#comment-13633201 ] Mark Miller commented on SOLR-4718: --- bq. I can't quite decide which should be the 'winner' for a config item that's in both solr.properties and solr.xml There will be no decision necessary on this - the two will not compete. This is all very simple stuff that already works and has been around in Solr for a long time. > 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 > > 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: > > > zkurl > whatever > > >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] [Updated] (SOLR-4358) SolrJ, by preventing multi-part post, loses key information about file name that Tika needs
[ https://issues.apache.org/jira/browse/SOLR-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-4358: Attachment: SOLR-4358.patch updated patch to allow get/set useMultiPartPost > SolrJ, by preventing multi-part post, loses key information about file name > that Tika needs > --- > > Key: SOLR-4358 > URL: https://issues.apache.org/jira/browse/SOLR-4358 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Karl Wright >Assignee: Ryan McKinley > Attachments: SOLR-4358.patch, SOLR-4358.patch > > > SolrJ accepts a ContentStream, which has a name field. Within > HttpSolrServer.java, if SolrJ makes the decision to use multipart posts, this > filename is transmitted as part of the form boundary information. However, > if SolrJ chooses not to use multipart post, the filename information is lost. > This information is used by SolrCell (Tika) to make decisions about content > extraction, so it is very important that it makes it into Solr in one way or > another. Either SolrJ should set appropriate equivalent headers to send the > filename automatically, or it should force multipart posts when this > information is present. -- 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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633177#comment-13633177 ] Shawn Heisey commented on SOLR-4718: Guiding principle that I think needs to be observed: Any increase in complexity must come with a tangible benefit to a substantial percentage of the user base. I agree that solr.properties should only be disk-based. I can't quite decide which should be the 'winner' for a config item that's in both solr.properties and solr.xml, but I am leaning towards the .properties entry. In a world that includes both solr.properties and solr.xml, perhaps solr.xml becomes a truly global config file, affecting the whole cluster and living in zookeeper, with server-specific overrides living in solr.properties. If solr.xml lives in zookeeper, then how do we initially upload it or update it? Would a Solr restart be required for changes to take effect? Will it be possible to get SolrCloud started if the only thing you have is zkHost in solr.properties? Side issue: it would be really cool to be able to upload and partially update config sets (and possibly solr.xml) from within the admin UI, and/or with an API like /admin/cores. The current zookeeper bootstrap/cli is made for uploading named configs, but solr.xml is different, more global. I'm reluctant to keep expanding the commandline options for bootstrapping or zkcli, but perhaps a cluster-wide solr.xml is a good reason for it. > 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 > > 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: > > > zkurl > whatever > > >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] [Assigned] (SOLR-4358) SolrJ, by preventing multi-part post, loses key information about file name that Tika needs
[ https://issues.apache.org/jira/browse/SOLR-4358?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley reassigned SOLR-4358: --- Assignee: Ryan McKinley > SolrJ, by preventing multi-part post, loses key information about file name > that Tika needs > --- > > Key: SOLR-4358 > URL: https://issues.apache.org/jira/browse/SOLR-4358 > Project: Solr > Issue Type: Bug > Components: clients - java >Affects Versions: 4.0 >Reporter: Karl Wright >Assignee: Ryan McKinley > Attachments: SOLR-4358.patch > > > SolrJ accepts a ContentStream, which has a name field. Within > HttpSolrServer.java, if SolrJ makes the decision to use multipart posts, this > filename is transmitted as part of the form boundary information. However, > if SolrJ chooses not to use multipart post, the filename information is lost. > This information is used by SolrCell (Tika) to make decisions about content > extraction, so it is very important that it makes it into Solr in one way or > another. Either SolrJ should set appropriate equivalent headers to send the > filename automatically, or it should force multipart posts when this > information is present. -- 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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633161#comment-13633161 ] Ryan McKinley commented on SOLR-4718: - bq. Just always use ZK. I have not followed this dev much, but I assume we are still aiming to support a ZK free (non-cloud) deployment > 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 > > 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: > > > zkurl > whatever > > >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] [Updated] (SOLR-4671) CSV Should Support pseudo fields
[ https://issues.apache.org/jira/browse/SOLR-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-4671: Fix Version/s: 4.3 > CSV Should Support pseudo fields > > > Key: SOLR-4671 > URL: https://issues.apache.org/jira/browse/SOLR-4671 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.2 > Environment: Linux Server with Tomcat >Reporter: nihed mbarek >Assignee: Ryan McKinley > Fix For: 4.3 > > Attachments: result.csv, SOLR-4671-CSV-Pseudo-Fields.patch > > > We just discover that we can't have alias for CSV Formating > http://127.0.0.1:8983/solr/collection1/select?q=*%3A*&fl=score%2C+idprod%3Aid&wt=csv&indent=true > using this schema > https://issues.apache.org/jira/secure/attachment/12576952/schema.xml > for the standard core collection > => result as attachment -- 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-4671) CSV Should Support pseudo fields
[ https://issues.apache.org/jira/browse/SOLR-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-4671. - Resolution: Fixed fixed in trunk and 4x > CSV Should Support pseudo fields > > > Key: SOLR-4671 > URL: https://issues.apache.org/jira/browse/SOLR-4671 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.2 > Environment: Linux Server with Tomcat >Reporter: nihed mbarek >Assignee: Ryan McKinley > Attachments: result.csv, SOLR-4671-CSV-Pseudo-Fields.patch > > > We just discover that we can't have alias for CSV Formating > http://127.0.0.1:8983/solr/collection1/select?q=*%3A*&fl=score%2C+idprod%3Aid&wt=csv&indent=true > using this schema > https://issues.apache.org/jira/secure/attachment/12576952/schema.xml > for the standard core collection > => result as attachment -- 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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633151#comment-13633151 ] Erik Hatcher commented on SOLR-4718: bq. Just always use ZK. +1 What are the cons to always using ZK? Is there some performance or other efficiency to using local config files? Granted one wouldn't want to be pulling synonyms from ZK for every request. But there's at least the file size issue in ZK and some folks do have large synonym files and large ExternalFileField files or elevate.xml's. > 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 > > 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: > > > zkurl > whatever > > >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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633150#comment-13633150 ] Mark Miller commented on SOLR-4718: --- That's always been on the table, but I don't think it's very near term yet. I think dealing with config and what not in zk needs to advance quite a bit before we can push zk into non solrcloud mode or push non solrcloud mode into zk. Long term, I think it will end up simplifying a lot when that happens. > 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 > > 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: > > > zkurl > whatever > > >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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633140#comment-13633140 ] Eric Pugh commented on SOLR-4718: - So what about just making ZooKeeper a core part of Solr? Whether you are running traditional Solr, or running Solr Cloud, you still use ZooKeeper? I remember when we had either single core, or multiple core support in Solr back in version 1.4... And the logic was always "if single core, do X, else if multicore, then do Y".And eventually we moved to multicore everywhere, just sometimes you have a single core. So maybe everything is always in ZK, and the question is, is it a embedded ZK, which should be fine for typical use cases, or is it external ZK that you would want in a big setup. Eliminate this constant "am I in ZK or not"? Just always use ZK. > 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 > > 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: > > > zkurl > whatever > > >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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633137#comment-13633137 ] Mark Miller commented on SOLR-4718: --- It all should work the same way that solrcore.properties should work. It's should only be looked for locally - there is no need to put it in zk. This is roughly already in place with solrcore.properties like I said - there is not a lot of reason to tread new ground here. solr.properties and solr.xml have no precedence issues. Again, this works like solrcore.properties - these properties are used for sys prob variable substitution in solr.xml. No precedence to consider. We already have the machinery in place for almost all of this. The only special case will be zkhost. bq. zkSolrXmlPath -1 on this guy. We shouldn't support local anymore - only for back compat. I think there must be a better way to solve this. I plan on working on some of this as well. > 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 > > 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: > > > zkurl > whatever > > >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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633135#comment-13633135 ] Walter Underwood commented on SOLR-4718: What if one or both has a syntax error? Need rules for that, too. > 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 > > 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: > > > zkurl > whatever > > >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] [Updated] (SOLR-4671) CSV Should Support pseudo fields
[ https://issues.apache.org/jira/browse/SOLR-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley updated SOLR-4671: Attachment: SOLR-4671-CSV-Pseudo-Fields.patch expose the Requested field names in ReturnFields and use them in CSVResponseWriter (rather then the lucene field names) > CSV Should Support pseudo fields > > > Key: SOLR-4671 > URL: https://issues.apache.org/jira/browse/SOLR-4671 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.2 > Environment: Linux Server with Tomcat >Reporter: nihed mbarek >Assignee: Ryan McKinley > Attachments: result.csv, SOLR-4671-CSV-Pseudo-Fields.patch > > > We just discover that we can't have alias for CSV Formating > http://127.0.0.1:8983/solr/collection1/select?q=*%3A*&fl=score%2C+idprod%3Aid&wt=csv&indent=true > using this schema > https://issues.apache.org/jira/secure/attachment/12576952/schema.xml > for the standard core collection > => result as attachment -- 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-4703) Index Replication Fails Because SnapPuller doesn't pass indexversion info to Master
[ https://issues.apache.org/jira/browse/SOLR-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633131#comment-13633131 ] Umesh Prasad commented on SOLR-4703: The error occurred when my master was on Solr 3.6 and Slave on Solr 4.2 It worked correctly without patch once I switched master and Slave both on Solr 4.2. Both machines were on prod cluster. I have not tried to do a test setup. > Index Replication Fails Because SnapPuller doesn't pass indexversion info to > Master > --- > > Key: SOLR-4703 > URL: https://issues.apache.org/jira/browse/SOLR-4703 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 4.2 >Reporter: Umesh Prasad > Labels: replication > Attachments: solr.replication.fetchFileList.trunk.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > Replication Sequence in Solr 4.2 is > 1. Get replicable indexVersion & Generation from Master > 2. Fetch File list for given indexVersion and Generation from Master > 3. Down the File list > Solr 4.2 and trunk have a Bug, whereby Slave doesn't pass the indexVersion to > Master. Master, informs the slave that indexVersion param is missing, but > slave ignores it and instead says that there are no filelists to down. > And replication breaks. > -- This message is automatically generated by JIRA. If you think it was sent incorrectly, please contact your JIRA administrators For more information on JIRA, see: http://www.atlassian.com/software/jira - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-4671) CSV Should Support pseudo fields
[ https://issues.apache.org/jira/browse/SOLR-4671?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley reassigned SOLR-4671: --- Assignee: Ryan McKinley > CSV Should Support pseudo fields > > > Key: SOLR-4671 > URL: https://issues.apache.org/jira/browse/SOLR-4671 > Project: Solr > Issue Type: Improvement >Affects Versions: 4.2 > Environment: Linux Server with Tomcat >Reporter: nihed mbarek >Assignee: Ryan McKinley > Attachments: result.csv > > > We just discover that we can't have alias for CSV Formating > http://127.0.0.1:8983/solr/collection1/select?q=*%3A*&fl=score%2C+idprod%3Aid&wt=csv&indent=true > using this schema > https://issues.apache.org/jira/secure/attachment/12576952/schema.xml > for the standard core collection > => result as attachment -- 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-4718) Allow solr.xml to be stored in zookeeper
[
https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633123#comment-13633123
]
Erick Erickson commented on SOLR-4718:
--
My head's exploding. We have two files, solr.xml and solr.properties, plus the
absence of either. Stored either locally or on ZK. What's the precedence here?
I vote that solr.properties be only local.
So, some straw-man rules
> solr.properties is irrelevant without a solr.xml, it's used only to sub in
> ${} type constructs.
> solr.properties can exists only locally. Don't look on ZK under any
> conditions.
> solr.properties definitions take precedence over _any_ definitions in
> solr.xml either local or from ZK.
Note: my objection to making it possible to store solr.properties in ZK is that
it complexifies things and one can centrally store a complete solr.xml file
there just as easily. I can be persuaded otherwise, but I want a real use case
not a theoretical one. We can always add that on later too. Except how does
this play when creating collections? I guess that's irrelevant, the solr home
is what counts.
> if solr.xml is local, we look for one on ZK iff zkSolrXmlPath is defined (in
> solr.xml or as a sysprop). Overlay the local one if so. Then apply
> solr.properties to the combined solr.xml
> if no solr.xml is found locally but zkRun or zkHost is defined (sys props),
> then look in ZK(root or sysprop zkSolrXmlPath) for solr.xml and use that.
> Overlay with local solr.properties if present.
# So the multiple war in single JVM case is handled; you don't have to have any
sysprops if you have a solr.xml/solr.properties pair defined in solrhome for
each war. And you can still define a minimal file that just points to ZK for
the "real" solr.xml file.
# The no-local-config case is handled by deciding to NOT have a solr.xml
locally, set the necessary sysprops (zkhost and possibly zkSolrXmlPath. With or
without a solr.properties file.
# The mixed case is handled by having remote solr.xml but local solr.properties
in each solrhome to override values.
> 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
>
> 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:
>
>
> zkurl
> whatever
>
>
>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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633052#comment-13633052 ] Mark Miller commented on SOLR-4718: --- There is related discussion in SOLR-4687 and SOLR-4622. > 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 > > 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: > > > zkurl > whatever > > >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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633045#comment-13633045 ] Mark Miller commented on SOLR-4718: --- The more I think about it the more I like that idea. A file called solr.properties can exist in solrhome, and if it does, it's used to substitute properties in solr.xml. zkhost can either go there, or as a sys prop on the cmd line. Like solrcore.properties (and most property files of this nature), it should be optional. It's simple, consistent with current design, and solves all of the open issues. > 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 > > 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: > > > zkurl > whatever > > >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] [Resolved] (SOLR-1351) facet on same field different ways
[ https://issues.apache.org/jira/browse/SOLR-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley resolved SOLR-1351. - Resolution: Fixed While the style is different then proposed in this patch, you can get the same results using localParams syntax from SOLR-4717 > facet on same field different ways > -- > > Key: SOLR-1351 > URL: https://issues.apache.org/jira/browse/SOLR-1351 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley >Assignee: Ryan McKinley > Fix For: 4.3 > > Attachments: SOLR-1351-B.patch, SOLR-1351-facet-same-field.patch, > SOLR-1351.patch > > > There is a general need to facet on the same field in different ways > (different prefixes, different filters). We need a way to express this. -- 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-4717) SimpleFacets should respect localParams
[
https://issues.apache.org/jira/browse/SOLR-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley resolved SOLR-4717.
-
Resolution: Fixed
added to 4x and trunk
> SimpleFacets should respect localParams
> ---
>
> Key: SOLR-4717
> URL: https://issues.apache.org/jira/browse/SOLR-4717
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-4717-FacetLocalParams.patch
>
>
> In trying to implement http://wiki.apache.org/solr/HierarchicalFaceting I
> found the need to send multiple prefix facets in the same request on the same
> field.
> Currently facet params will parse the localParams, but only use them to pick
> out a name. We can easily modify things to let localParams override global
> ones. For example:
> {code}
> &{!key=level3 facet.prefix=3/path/to/folder}path
> &{!key=level2 facet.prefix=2/path/to}path
> &{!key=level1 facet.prefix=1/path}path
> {code}
> This can easily be supported if we use:
> {code:java}
> params = SolrParams.wrapDefaults(localParams, orig);
> {code}
> when local params exist
> --
> We have come a long way from *simple* facets!
--
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-4717) SimpleFacets should respect localParams
[
https://issues.apache.org/jira/browse/SOLR-4717?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633028#comment-13633028
]
Ryan McKinley commented on SOLR-4717:
-
Hoss, thanks for pointing me to SOLR-1351. I just ported the tests to work with
localParams.
SOLR-1387 seems like a different beast
> SimpleFacets should respect localParams
> ---
>
> Key: SOLR-4717
> URL: https://issues.apache.org/jira/browse/SOLR-4717
> Project: Solr
> Issue Type: Improvement
>Reporter: Ryan McKinley
>Assignee: Ryan McKinley
> Attachments: SOLR-4717-FacetLocalParams.patch
>
>
> In trying to implement http://wiki.apache.org/solr/HierarchicalFaceting I
> found the need to send multiple prefix facets in the same request on the same
> field.
> Currently facet params will parse the localParams, but only use them to pick
> out a name. We can easily modify things to let localParams override global
> ones. For example:
> {code}
> &{!key=level3 facet.prefix=3/path/to/folder}path
> &{!key=level2 facet.prefix=2/path/to}path
> &{!key=level1 facet.prefix=1/path}path
> {code}
> This can easily be supported if we use:
> {code:java}
> params = SolrParams.wrapDefaults(localParams, orig);
> {code}
> when local params exist
> --
> We have come a long way from *simple* facets!
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Assigned] (SOLR-1351) facet on same field different ways
[ https://issues.apache.org/jira/browse/SOLR-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Ryan McKinley reassigned SOLR-1351: --- Assignee: Ryan McKinley > facet on same field different ways > -- > > Key: SOLR-1351 > URL: https://issues.apache.org/jira/browse/SOLR-1351 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley >Assignee: Ryan McKinley > Fix For: 4.3 > > Attachments: SOLR-1351-B.patch, SOLR-1351-facet-same-field.patch, > SOLR-1351.patch > > > There is a general need to facet on the same field in different ways > (different prefixes, different filters). We need a way to express this. -- 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-1351) facet on same field different ways
[
https://issues.apache.org/jira/browse/SOLR-1351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Ryan McKinley updated SOLR-1351:
Attachment: SOLR-1351-facet-same-field.patch
adding tests from these patches.
Rather then:
{code}
+,"facet.date", "{!key=foo}" + f
+,"f.foo.facet.date.start", "1976-07-01T00:00:00.000Z"
+,"f.foo.facet.date.end",
"1976-07-01T00:00:00.000Z+1MONTH"
+,"f.foo.facet.date.gap", "+1DAY"
+,"f.foo.facet.date.other", "all"
+,"facet.date", "{!key=bar}" + f
+,"f.bar.facet.date.start", "1976-07-01T00:00:00.000Z"
+,"f.bar.facet.date.end", "1976-07-01T00:00:00.000Z+7DAY"
+,"f.bar.facet.date.gap", "+1DAY"
{code}
We now have:
{code}
,"facet.date", "{!key=foo " +
"facet.date.start=1976-07-01T00:00:00.000Z " +
"facet.date.end=1976-07-01T00:00:00.000Z+1MONTH " +
"facet.date.gap=+1DAY " +
"facet.date.other=all " +
"}" + f
,"facet.date", "{!key=bar " +
"facet.date.start=1976-07-01T00:00:00.000Z " +
"facet.date.end=1976-07-01T00:00:00.000Z+7DAY " +
"facet.date.gap=+1DAY " +
"}" + f
{code}
> facet on same field different ways
> --
>
> Key: SOLR-1351
> URL: https://issues.apache.org/jira/browse/SOLR-1351
> Project: Solr
> Issue Type: Improvement
>Reporter: Yonik Seeley
> Fix For: 4.3
>
> Attachments: SOLR-1351-B.patch, SOLR-1351-facet-same-field.patch,
> SOLR-1351.patch
>
>
> There is a general need to facet on the same field in different ways
> (different prefixes, different filters). We need a way to express this.
--
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-4703) Index Replication Fails Because SnapPuller doesn't pass indexversion info to Master
[ https://issues.apache.org/jira/browse/SOLR-4703?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13633001#comment-13633001 ] Hoss Man commented on SOLR-4703: I must be missing something here... can you elaborate on the basic steps to reproduce this bug, because when i try to setup a simple test case with a single maste & slave configured with replication, the slave does correctly pull updates from the master. > Index Replication Fails Because SnapPuller doesn't pass indexversion info to > Master > --- > > Key: SOLR-4703 > URL: https://issues.apache.org/jira/browse/SOLR-4703 > Project: Solr > Issue Type: Bug > Components: replication (java) >Affects Versions: 4.2 >Reporter: Umesh Prasad > Labels: replication > Attachments: solr.replication.fetchFileList.trunk.patch > > Original Estimate: 1h > Remaining Estimate: 1h > > Replication Sequence in Solr 4.2 is > 1. Get replicable indexVersion & Generation from Master > 2. Fetch File list for given indexVersion and Generation from Master > 3. Down the File list > Solr 4.2 and trunk have a Bug, whereby Slave doesn't pass the indexVersion to > Master. Master, informs the slave that indexVersion param is missing, but > slave ignores it and instead says that there are no filelists to down. > And replication breaks. > -- 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-3419) XSS vulnerability in the json.wrf parameter
[ https://issues.apache.org/jira/browse/SOLR-3419?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632997#comment-13632997 ] James Frank commented on SOLR-3419: --- Just an agreement that this should be resolved and SOLR should be sanitize the json.wrf callback. We are facing an issue where this vulnerability was pulled up in a security scan and we will need to implement external sanitization through a proxy in order to resolve it. This is really something that should be happening internally. > XSS vulnerability in the json.wrf parameter > --- > > Key: SOLR-3419 > URL: https://issues.apache.org/jira/browse/SOLR-3419 > Project: Solr > Issue Type: Bug > Components: Response Writers >Affects Versions: 3.5 >Reporter: Prafulla Kiran >Priority: Minor > > There's no filtering of the wrapper function name passed to the solr search > service > If the name of the wrapper function passed to the solr query service is the > following string - > %3C!doctype%20html%3E%3Chtml%3E%3Cbody%3E%3Cimg%20src=%22x%22%20onerror=%22alert%281%29%22%3E%3C/body%3E%3C/html%3E > solr passes the string back as-is which results in an XSS attack in browsers > like IE-7 which perform mime-sniffing. In any case, the callback function in > a jsonp response should always be sanitized - > http://stackoverflow.com/questions/2777021/do-i-need-to-sanitize-the-callback-parameter-from-a-jsonp-call -- 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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632980#comment-13632980 ] Mark Miller commented on SOLR-4718: --- bq. cons - can't run multiple JVMs pointing to different files. Is this really a problem? Hossman had a few cons he listed out in another issue - I don't think multiple JVMs has a problem with system properties - it's running multiple Solr wars within a single JVM that has a problem. I think one simple idea to handle is this is something much like solrcore.properties and solrconfig.xml. solrcore.properties is auto loaded and used for sys prop resolution on solrconfig.xml - you could imagine the same mechanism for solr.xml, but where the properties file is also picked up in a local solr.home location. Now you can put any local config overrides in this file. It could be required that zkhost is put either in the properties file or passed by sys prop. > 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 > > 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: > > > zkurl > whatever > > >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-4718) Allow solr.xml to be stored in zookeeper
[ https://issues.apache.org/jira/browse/SOLR-4718?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13632966#comment-13632966 ] Mark Miller commented on SOLR-4718: --- bq. More interesting is how to get the configuration into ZK in the first place, enhancements to ZkCli? Or boostrap-conf? Other? I think this is one of the most important pieces - solr.xml must still be easy to edit - I don't think we should commit anything that leaves this piece out. The rest of this seems totally straightforward - the biggest downside is going to be the increased pain in working with solr.xml, and so we need to minimize that as much as possible. > 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 > > 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: > > > zkurl > whatever > > >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
