[jira] Created: (SOLR-722) CoreContainer.reload should make core aliases point to reloaded core
CoreContainer.reload should make core aliases point to reloaded core Key: SOLR-722 URL: https://issues.apache.org/jira/browse/SOLR-722 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Henri Biestro CoreContainer.reload does only make the SolrCore name point to the reloaded core. Since loading (creating) a core creates all aliases for that core, reload should do the same. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-723) SolrCore & aliasing/swapping may lead to confusing JMX
SolrCore & aliasing/swapping may lead to confusing JMX -- Key: SOLR-723 URL: https://issues.apache.org/jira/browse/SOLR-723 Project: Solr Issue Type: Bug Affects Versions: 1.3 Reporter: Henri Biestro Priority: Minor As mentioned by Yonik in SOLR-647, JMX registers the core with its name. After swapping or re-aliasing the core, the JMX tracking name does not correspond to the actual core anymore. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Solr nightly build failure
init-forrest-entities: [mkdir] Created dir: /tmp/apache-solr-nightly/build [mkdir] Created dir: /tmp/apache-solr-nightly/build/web compile-common: [mkdir] Created dir: /tmp/apache-solr-nightly/build/common [javac] Compiling 36 source files to /tmp/apache-solr-nightly/build/common [javac] Note: /tmp/apache-solr-nightly/src/java/org/apache/solr/common/util/FastInputStream.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile: [mkdir] Created dir: /tmp/apache-solr-nightly/build/core [javac] Compiling 338 source files to /tmp/apache-solr-nightly/build/core [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile-solrj-core: [mkdir] Created dir: /tmp/apache-solr-nightly/build/client/solrj [javac] Compiling 26 source files to /tmp/apache-solr-nightly/build/client/solrj [javac] Note: /tmp/apache-solr-nightly/client/java/solrj/src/org/apache/solr/client/solrj/impl/CommonsHttpSolrServer.java uses or overrides a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. compile-solrj: [javac] Compiling 2 source files to /tmp/apache-solr-nightly/build/client/solrj compileTests: [mkdir] Created dir: /tmp/apache-solr-nightly/build/tests [javac] Compiling 113 source files to /tmp/apache-solr-nightly/build/tests [javac] Note: Some input files use or override a deprecated API. [javac] Note: Recompile with -Xlint:deprecation for details. [javac] Note: Some input files use unchecked or unsafe operations. [javac] Note: Recompile with -Xlint:unchecked for details. junit: [mkdir] Created dir: /tmp/apache-solr-nightly/build/test-results [junit] Running org.apache.solr.BasicFunctionalityTest [junit] Tests run: 19, Failures: 0, Errors: 0, Time elapsed: 21.729 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 11.409 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 8.41 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 3.14 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 3.49 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.754 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.967 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 32.471 sec [junit] 2008-08-25 08:09:12.796::INFO: Shutdown hook executing [junit] 2008-08-25 08:09:12.797::INFO: Shutdown hook complete [junit] 2008-08-25 08:09:13.804::INFO: Shutdown hook complete [junit] 2008-08-25 08:09:14.813::INFO: Shutdown hook complete [junit] 2008-08-25 08:09:15.823::INFO: Shutdown hook complete [junit] 2008-08-25 08:09:16.833::INFO: Shutdown hook complete [junit] 2008-08-25 08:09:17.842::INFO: Shutdown hook complete [junit] 2008-08-25 08:09:18.852::INFO: Shutdown hook complete [junit] 2008-08-25 08:09:19.862::INFO: Shutdown hook complete [junit] 2008-08-25 08:09:20.872::INFO: Shutdown hook complete [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.169 sec [junit] Running org.apache.solr.analysis.HTMLStripReaderTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 0.915 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.878 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.074 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.131 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.901 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.953 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures:
[jira] Created: (SOLR-724) CoreDescriptor.{get,set}CoreExpressions should probably not be public (but package private)
CoreDescriptor.{get,set}CoreExpressions should probably not be public (but
package private)
---
Key: SOLR-724
URL: https://issues.apache.org/jira/browse/SOLR-724
Project: Solr
Issue Type: Bug
Affects Versions: 1.3
Reporter: Henri Biestro
Priority: Minor
Exposing them precludes being ever able to fill the CoreDescriptor with
property expressions.
Since a 'public' method can not be removed easily, this is a future problem.
Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreExpressions should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625277#action_12625277
]
Shalin Shekhar Mangar commented on SOLR-724:
I think you mean get/set coreProperties.
I don't think there's a problem. These methods can continue to be used for
properties (evaluated expressions). We can always keep another object for
un-evaluated expressions for persisting them back.
> CoreDescriptor.{get,set}CoreExpressions should probably not be public (but
> package private)
> ---
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
CoreContainer/CoreDescriptor/SolrCore cleansing --- Key: SOLR-725 URL: https://issues.apache.org/jira/browse/SOLR-725 Project: Solr Issue Type: Improvement Affects Versions: 1.3 Reporter: Henri Biestro These 3 classes and the name vs alias handling are somewhat confusing. The recent SOLR-647 & SOLR-716 have created a bit of a flux. This issue attemps to clarify the model and the list of operations. h3. CoreDescriptor: describes the parameters of a SolrCore h4. Definitions * has one name ** The CoreDescriptor name may represent multiple aliases; in that case, first alias is the SolrCore name * has one instance directory location * has one config & schema name h4. Operations The class is only a parameter passing facility h3. SolrCore: manages a Lucene index h4. Definitions * has one unique *name* (in the CoreContainer) ** the *name* is used in JMX to identify the core * has one current set of *aliases* ** the name is the first alias h4. Name & alias operations * *get name/aliases*: obvious * *alias*: adds an alias to this SolrCore * *unalias*: removes an alias from this SolrCore * *name*: sets the SolrCore name ** potentially impacts JMX registration * *rename*: picks a new name from the SolrCore aliases ** triggered when alias name is already in use h3. CoreContainer: manages all relations between cores & descriptors h4. Definitions * has a set of aliases (each of them pointing to one core) ** ensure alias uniqueness. h4. SolrCore instance operations * *load*: makes a SolrCore available for requests ** creates a SolrCore ** registers all SolrCore aliases in the aliases set ** (load = create + register) * *unload*: removes a core idenitified by one of its aliases ** stops handling the Lucene index ** all SolrCore aliases are removed * *reload*: recreate the core identified by one of its aliases * *create*: create a core from a CoreDescriptor ** readies up the Lucene index * *register*: registers all aliases of a SolrCore h4. SolrCore alias operations * *swap*: swaps 2 aliases ** method: swap * *alias*: creates 1 alias for a core, potentially unaliasing a previously used alias ** The SolrCore name being an alias, this operation might trigger a SolrCore rename * *unalias*: removes 1 alias for a core ** The SolrCore name being an alias, this operation might trigger a SolrCore rename -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Henri Biestro updated SOLR-725: --- Attachment: solr-725.patch The patch solves the 3 issues this relates to. The SolrCore handles its name & makes JMX follow potential renames. CoreDescriptor does not expose more than necessary (& protects the possibility of SOLR-646 property expression features). CoreContainer is refactored to be a bit more efficient wrt cores locking & SolrCore alias/name handling. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625286#action_12625286 ] Noble Paul commented on SOLR-725: - I wish to know a few things. * Is anybody using the alias feature? * If yes , what is the usecase? The alias feature implementation confuses me and the behavior seems to be very inconsistent. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreExpressions should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625287#action_12625287
]
Henri Biestro commented on SOLR-724:
Yes, correct; properties, not expressions.
They are unnecessary since the CoreContainer & each SolrCore resource loader
could (will hopefully) contain the evaluated properties.
That would make 2 places where we can access them & this seems redundant.
I'm just trying to reduce public method exposure.
> CoreDescriptor.{get,set}CoreExpressions should probably not be public (but
> package private)
> ---
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Henri Biestro updated SOLR-724:
---
Summary: CoreDescriptor.{get,set}CoreProperties should probably not be
public (but package private) (was: CoreDescriptor.{get,set}CoreExpressions
should probably not be public (but package private))
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625289#action_12625289
]
Noble Paul commented on SOLR-724:
-
bq.I'm just trying to reduce public method exposure.
There is no harm is exposing methods as long as we are exposing immutable
stuff. It can actually enable a lot of components to get information w/o
raising new issues in JIRA
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625304#action_12625304
]
Henri Biestro commented on SOLR-725:
About being inconsistent, this is what this issue attempts to solve. :-)
And, yes, aliasing is a usefull feature: this allows to have one webapp path
that's constant for users (or links to persist) and allows to change the index
when reindexing is needed (reload is only good enough for non-schema related
modifications) without fuss..
Say you have your core declared as:
{code:xml}
{code}
Users refer to it through its *public* alias.
When you make schema/indexing changes that necessitate reindexing (hcnage
stopwords, stemming, etc):
# create your new core as 'version-3.0,dev'
# reindex the content
# verify your preferred queries do work appropriately
# alias('public', 'versions-3.0') ; which changes the link to point to the new
version and closes the old one (as soon as all queries have finished running)
# unalias('dev'); so you are ready for next version
> CoreContainer/CoreDescriptor/SolrCore cleansing
> ---
>
> Key: SOLR-725
> URL: https://issues.apache.org/jira/browse/SOLR-725
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Henri Biestro
> Attachments: solr-725.patch
>
>
> These 3 classes and the name vs alias handling are somewhat confusing.
> The recent SOLR-647 & SOLR-716 have created a bit of a flux.
> This issue attemps to clarify the model and the list of operations.
> h3. CoreDescriptor: describes the parameters of a SolrCore
> h4. Definitions
> * has one name
> ** The CoreDescriptor name may represent multiple aliases; in that
> case, first alias is the SolrCore name
> * has one instance directory location
> * has one config & schema name
> h4. Operations
> The class is only a parameter passing facility
> h3. SolrCore: manages a Lucene index
> h4. Definitions
> * has one unique *name* (in the CoreContainer)
> **the *name* is used in JMX to identify the core
> * has one current set of *aliases*
> **the name is the first alias
> h4. Name & alias operations
> * *get name/aliases*: obvious
> * *alias*: adds an alias to this SolrCore
> * *unalias*: removes an alias from this SolrCore
> * *name*: sets the SolrCore name
> **potentially impacts JMX registration
> * *rename*: picks a new name from the SolrCore aliases
> **triggered when alias name is already in use
> h3. CoreContainer: manages all relations between cores & descriptors
> h4. Definitions
> * has a set of aliases (each of them pointing to one core)
> **ensure alias uniqueness.
> h4. SolrCore instance operations
> * *load*: makes a SolrCore available for requests
> **creates a SolrCore
> **registers all SolrCore aliases in the aliases set
> **(load = create + register)
> * *unload*: removes a core idenitified by one of its aliases
> **stops handling the Lucene index
> **all SolrCore aliases are removed
> * *reload*: recreate the core identified by one of its aliases
> * *create*: create a core from a CoreDescriptor
> **readies up the Lucene index
> * *register*: registers all aliases of a SolrCore
>
> h4. SolrCore alias operations
> * *swap*: swaps 2 aliases
> **method: swap
> * *alias*: creates 1 alias for a core, potentially unaliasing a
> previously used alias
> **The SolrCore name being an alias, this operation might trigger
> a SolrCore rename
> * *unalias*: removes 1 alias for a core
> **The SolrCore name being an alias, this operation might trigger
> a SolrCore rename
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625305#action_12625305
]
Henri Biestro commented on SOLR-724:
I'm confused about when the 'what-if' rule can apply or not wrt public methods.
My understanding was that till a use-case exists, we shouldn't publicly expose
the method ( and it's been quite a hard lesson... :-) )
Besides, the SolrResourceLoader *is* available from everywhere.
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[
https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625309#action_12625309
]
Noble Paul commented on SOLR-725:
-
bq. When you make schema/indexing changes that necessitate reindexing (hcnage
stopwords, stemming, etc):
We are already doing this in SOLR-561 . What we do is after we make the
necessary changes do a reload.
I see your point of verifying the core .
Why is it not possible with the following steps?
# create('version-3.0,dev')
# reindex the content
# verify your preferred queries do work appropriately
# swap ('public', 'versions-3.0')
# unload('versions-3.0')
> CoreContainer/CoreDescriptor/SolrCore cleansing
> ---
>
> Key: SOLR-725
> URL: https://issues.apache.org/jira/browse/SOLR-725
> Project: Solr
> Issue Type: Improvement
>Affects Versions: 1.3
>Reporter: Henri Biestro
> Attachments: solr-725.patch
>
>
> These 3 classes and the name vs alias handling are somewhat confusing.
> The recent SOLR-647 & SOLR-716 have created a bit of a flux.
> This issue attemps to clarify the model and the list of operations.
> h3. CoreDescriptor: describes the parameters of a SolrCore
> h4. Definitions
> * has one name
> ** The CoreDescriptor name may represent multiple aliases; in that
> case, first alias is the SolrCore name
> * has one instance directory location
> * has one config & schema name
> h4. Operations
> The class is only a parameter passing facility
> h3. SolrCore: manages a Lucene index
> h4. Definitions
> * has one unique *name* (in the CoreContainer)
> **the *name* is used in JMX to identify the core
> * has one current set of *aliases*
> **the name is the first alias
> h4. Name & alias operations
> * *get name/aliases*: obvious
> * *alias*: adds an alias to this SolrCore
> * *unalias*: removes an alias from this SolrCore
> * *name*: sets the SolrCore name
> **potentially impacts JMX registration
> * *rename*: picks a new name from the SolrCore aliases
> **triggered when alias name is already in use
> h3. CoreContainer: manages all relations between cores & descriptors
> h4. Definitions
> * has a set of aliases (each of them pointing to one core)
> **ensure alias uniqueness.
> h4. SolrCore instance operations
> * *load*: makes a SolrCore available for requests
> **creates a SolrCore
> **registers all SolrCore aliases in the aliases set
> **(load = create + register)
> * *unload*: removes a core idenitified by one of its aliases
> **stops handling the Lucene index
> **all SolrCore aliases are removed
> * *reload*: recreate the core identified by one of its aliases
> * *create*: create a core from a CoreDescriptor
> **readies up the Lucene index
> * *register*: registers all aliases of a SolrCore
>
> h4. SolrCore alias operations
> * *swap*: swaps 2 aliases
> **method: swap
> * *alias*: creates 1 alias for a core, potentially unaliasing a
> previously used alias
> **The SolrCore name being an alias, this operation might trigger
> a SolrCore rename
> * *unalias*: removes 1 alias for a core
> **The SolrCore name being an alias, this operation might trigger
> a SolrCore rename
>
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625317#action_12625317 ] Henri Biestro commented on SOLR-725: bq. What we do is after we make the necessary changes do a reload. You lost me here; reindexing implies you loaded the core already. Guess you mean that *after* reindexing, you can replicate & slaves only have to reload? bq. is it not possible with the following steps? Correct, this is another useful way of using aliases to achieve the same. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CoreContainer can store the appcontext, host and port of the Solr application
Might be irrelevant but do we have to store this information in the CoreContainer ? Couldn't we use core-container (master) & core properties (slave) to store that information ? These would be filled from the servlet filter (on the master side) in the core-container properties. To make them widely available to handlers, these properties should be accessible through the SolrResourceLoader (which is accessible easily). -- View this message in context: http://www.nabble.com/CoreContainer-can-store-the-appcontext%2C-host-and-port-of-the-Solr-application-tp19138302p19141820.html Sent from the Solr - Dev mailing list archive at Nabble.com.
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625319#action_12625319
]
Noble Paul commented on SOLR-724:
-
bq.Besides, the SolrResourceLoader is available from everywhere.
But , if there is something private in that class it should be fine . right?
bq.My understanding was that till a use-case exists..
Because Solr is also an API there are a lot of requesthandlers which people
write may find some info useful. We can go one step ahead and think "will it
hurt if this is public?" . Moreover , even if something is private I can easily
access the value through reflection. So the kind of security it offers is just
not real
The only advantage I see is that , if you wish to remove something it is easy
if something is not public. So if some feature is experimental it can be kept
not public
Another question to ask before making things public is that can the user can
alter some state in a way that can affect the functionality. If it is purely a
read-only state I guess it should be OK
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625326#action_12625326 ] Noble Paul commented on SOLR-725: - bq.What we do is after we make the necessary changes do a reload. We just blindly do a reload assuming everything is fine. So no testing. bq.Correct, this is another useful way of using aliases to achieve the same. This does not look like a useful way of using aliases. This is one extra step which could have been avoided According to me the *alias* feature is implemented in a very wrong way.Because of that some commonly used methods have no consistency SolrCore#getName(), CoreDescriptor#getName() etc . Moreover I am yet to see a valid usecase. I just wonder why it is there > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: CoreContainer can store the appcontext, host and port of the Solr application
On Mon, Aug 25, 2008 at 4:38 PM, Henrib <[EMAIL PROTECTED]> wrote: > > > Might be irrelevant but do we have to store this information in the > CoreContainer ? I am not much worried about where we store it. CoreContainer just occurred me as an easy place . The problem we are trying to solve is non-availability of this information anywhere . > Couldn't we use core-container (master) & core properties (slave) to store > that information ? > These would be filled from the servlet filter (on the master side) in the > core-container properties. > To make them widely available to handlers, these properties should be > accessible through the SolrResourceLoader (which is accessible easily). > > > -- > View this message in context: > http://www.nabble.com/CoreContainer-can-store-the-appcontext%2C-host-and-port-of-the-Solr-application-tp19138302p19141820.html > Sent from the Solr - Dev mailing list archive at Nabble.com. > > -- --Noble Paul
[jira] Updated: (SOLR-617) Allow configurable deletion policy
[
https://issues.apache.org/jira/browse/SOLR-617?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Akshay K. Ukey updated SOLR-617:
Attachment: solr-617.patch
This patch adds support for the configuration described in the issue
description.
> Allow configurable deletion policy
> --
>
> Key: SOLR-617
> URL: https://issues.apache.org/jira/browse/SOLR-617
> Project: Solr
> Issue Type: New Feature
> Components: search, update
>Affects Versions: 1.4
>Reporter: Noble Paul
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.4
>
> Attachments: solr-617.patch
>
>
> Lucene API provides means to configure deletion policy. Solr should be able
> to expose it through configuration in solrconfig.xml. Moreover the new
> replication (SOLR-561) strategy is going to rely on this .
> I propose the configuration go into the section
> sample configuration
> {code:xml|title=solrconfig.xml}
>
>
>
>
> true
>
>
>
>
>
>
>
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: Solr nightly build failure
On Aug 22, 2008, at 6:43 PM, Chris Hostetter wrote: : Can you double check which ant is geting used and make changes as appropriate? Actually, wait a minute nightly.sh is just running "ant nightly" which is the same as "ant test package" ... people who want to run tests and package things up shouldn't be required to have Maven ant tasks available. It looks like this started happening because of r687335 ... the new create-pacakges target seems fine to me ... but "package" and "generate-maven-artifacts" should each depend on it directly (and independently) ... why does "package" need to depend on "generate-maven-artifacts" ? Because the maven artifacts are part of packaging for release. People who don't want them can run "create-package", or we could call it core- package. I just thought for release purposes it's easier to just call one target that has it all. The bigger ? in my mind is why do we have two different nightly builds? Hudson and crontab.
Re: CoreContainer can store the appcontext, host and port of the Solr application
Noble Paul നോബിള് नोब्ळ् wrote: > > I am not much worried about where we store it. CoreContainer just > occurred me as an easy place . The problem we are trying to solve is > non-availability of this information anywhere . > We are in no functional disagreement and I'm merely trying to point an opportunistic feature reuse. Oh well.. -- View this message in context: http://www.nabble.com/CoreContainer-can-store-the-appcontext%2C-host-and-port-of-the-Solr-application-tp19138302p19143418.html Sent from the Solr - Dev mailing list archive at Nabble.com.
1.3 status
So, what's our status? It appears everything is closed. Do people feel comfortable w/ where we are at? There has been a whole flurry of changes in recent weeks (let's not do that again right before a release, eh?) Shall I go forward w/ creating some a release candidate? -Grant
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625347#action_12625347 ] Henri Biestro commented on SOLR-725: bq . This does not look like a useful way of using aliases. This is one extra step which could have been avoided. You used aliases in your own example. So I must have missed your point. bq. We just blindly do a reload assuming everything is fine. So no testing. Your operational rules are different than those I'm constrained to. I'm merely trying to contribute back the solution to some problems I've encountered. bq . the alias feature is implemented in a very wrong way Again, this is what this issue attempts to address. It's not intended to be confrontational. bq. I am yet to see a valid usecase. Besides those already mentioned (& I guess Yonik may have more since he introduced aliasessolving solr-647), there are plenty of other features that can come out from having a different path to use the same core; security, rendering, etc. Courtesy aside, I do respect functional needs of others & their implications although I don't understand all of them; I wish this was a community value. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625346#action_12625346
]
Henri Biestro commented on SOLR-724:
When a method is public, it also has to be maintained & up-compatible; if you
write a component that uses some private methods or members, that's your
prerogative but there is no guarantee from Apache that it's existence and
behavior will remain in the future.
In this issue, I'm stating that exposing Properties in the CoreDescriptor is
hindering future evolution because they will have to be maintained, that the
same information should be available from what I consider a narrower scope
location that does not reduce the functional possibilities.
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 1.3 status
Given that there are backward compat concerns with https://issues.apache.org/jira/browse/LUCENE-1142 perhaps we should update Lucene again before a release? -Yonik On Mon, Aug 25, 2008 at 9:02 AM, Grant Ingersoll <[EMAIL PROTECTED]> wrote: > So, what's our status? It appears everything is closed. Do people feel > comfortable w/ where we are at? There has been a whole flurry of changes in > recent weeks (let's not do that again right before a release, eh?) > > Shall I go forward w/ creating some a release candidate? > > -Grant >
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625359#action_12625359 ] Otis Gospodnetic commented on SOLR-725: --- Paul - I haven't looked at Henri's patch, but like Henri I also don't follow your logic. You give an example of using core alias (using swap), but then say you don't see a use case for it. Could you please explain? Also, thank you Henri for pushing this forward. I haven't paid very close attention to all the new *Core* classes and couldn't tell you which one does what without studying the code and reading a pile of JIRA comments. Do you think this can wait to be committed after 1.3 is out (i.e. no need to stop working on it, just don't commit so we don't delay 1.3 more). > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625363#action_12625363 ] Shalin Shekhar Mangar commented on SOLR-725: Henri -- Can you please attach the relevant parts of this patch to SOLR-723 to fix the JMX issues? > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 1.3 status
On Aug 25, 2008, at 9:48 AM, Yonik Seeley wrote: Given that there are backward compat concerns with https://issues.apache.org/jira/browse/LUCENE-1142 perhaps we should update Lucene again before a release? +1 Erik
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625365#action_12625365 ] Yonik Seeley commented on SOLR-725: --- bq. According to me the alias feature is implemented in a very wrong way.Because of that some commonly used methods have no consistency SolrCore#getName(), CoreDescriptor#getName() etc . Another way to think about it is that a core should be independent of how it is named or accessed (via HTTP, etc)... it has no inherent name, but CoreContainer is a way of allowing access by name, and SolrDispatchFilter allows access by name over HTTP (via CoreContainer's names). So in this mental model, it's SolrCore#getName() and CoreDescriptor#getName() that don't make sense. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 1.3 status
+1 for Lucene upgrade +1 for a release (I *think* none of the recent SOLR-7** issues have to go in 1.3) Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: Erik Hatcher <[EMAIL PROTECTED]> > To: solr-dev@lucene.apache.org > Sent: Monday, August 25, 2008 10:06:46 AM > Subject: Re: 1.3 status > > > On Aug 25, 2008, at 9:48 AM, Yonik Seeley wrote: > > Given that there are backward compat concerns with > > https://issues.apache.org/jira/browse/LUCENE-1142 > > perhaps we should update Lucene again before a release? > > +1 > > Erik
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625369#action_12625369
]
Shalin Shekhar Mangar commented on SOLR-724:
I feel that CoreContainer and CoreDescriptor seem to be the most logical place
to *find* the properties since they directly correspond to the and
elements in solr.xml and SolrResourceLoader is the most logical place to
*use* them since that's what we use to load config files. I think it should be
OK to keep both the ways.
Thoughts?
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 1.3 status
+1 for Lucene upgrade +1 for a release candidate. I think the newer issues can make it to 1.3.1 easily. We don't need to halt 1.3 for them. A general question -- how long does a Release Candidate phase lasts? On Mon, Aug 25, 2008 at 7:51 PM, Otis Gospodnetic < [EMAIL PROTECTED]> wrote: > +1 for Lucene upgrade > +1 for a release (I *think* none of the recent SOLR-7** issues have to go > in 1.3) > > > Otis > -- > Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch > > > > - Original Message > > From: Erik Hatcher <[EMAIL PROTECTED]> > > To: solr-dev@lucene.apache.org > > Sent: Monday, August 25, 2008 10:06:46 AM > > Subject: Re: 1.3 status > > > > > > On Aug 25, 2008, at 9:48 AM, Yonik Seeley wrote: > > > Given that there are backward compat concerns with > > > https://issues.apache.org/jira/browse/LUCENE-1142 > > > perhaps we should update Lucene again before a release? > > > > +1 > > > > Erik > > -- Regards, Shalin Shekhar Mangar.
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625377#action_12625377
]
Henri Biestro commented on SOLR-724:
Obviously different :-)
In my mind, these are resources of the core-container / cores; resources are
accessed through their respective ResourceLoader.
And the CoreDescriptor is, at its name hints, a parameter; it should not play
any active role besides carrying data to create a SolrCore (and should not be
used beyond that role).
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 1.3 status
On Aug 25, 2008, at 10:30 AM, Shalin Shekhar Mangar wrote: +1 for Lucene upgrade +1 for a release candidate. I think the newer issues can make it to 1.3.1 easily. We don't need to halt 1.3 for them. A general question -- how long does a Release Candidate phase lasts? In Lucene Java, we typically freeze for 10 days, during which only blockers and documentation patches are allowed to be committed. I'd be fine w/ 7, but what's 3 more days, right? -Grant
[jira] Commented: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625390#action_12625390
]
Mark Miller commented on SOLR-724:
--
I agree with Henri.
Having these methods public ties core properties to the CoreDescriptor for no
apparent good reason. This has the possibility of being an annoyance down the
road. Unless specifically needed, why create this burden? Keeping the link
between core properties and the descriptor package private allows for more
flexibility in the future - and will keep users happier - we don't want to have
to deprecate and change user exposed APIs if we can help it.
bq. My understanding was that till a use-case exists, we shouldn't publicly
expose the method ( and it's been quite a hard lesson... )
I think this is a great rule of thumb, and should be the guiding principal
here. Whats the use case that this solves beyond what using the resource loader
provides? The benefit should clearly outweigh having to maintain/support the
public API.
bq. Another question to ask before making things public is that can the user
can alter some state in a way that can affect the functionality. If it is
purely a read-only state I guess it should be OK
I think it goes further than this - there is a public link between the
descriptor and the core properties. Its not a huge issue obviously, but there
should be good reason for publicly linking two classes I think - the fact that
the implementation contains the linked class privately doesn't seem like a very
good reason.
- Mark
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Priority: Minor
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Resolved: (SOLR-724) CoreDescriptor.{get,set}CoreProperties should probably not be public (but package private)
[
https://issues.apache.org/jira/browse/SOLR-724?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Shalin Shekhar Mangar resolved SOLR-724.
Resolution: Fixed
Fix Version/s: 1.3
Assignee: Shalin Shekhar Mangar
Committed revision 688751.
Bowing down to public demand :-)
Changing the methods to package private to insulate the public API from
internal changes.
> CoreDescriptor.{get,set}CoreProperties should probably not be public (but
> package private)
> --
>
> Key: SOLR-724
> URL: https://issues.apache.org/jira/browse/SOLR-724
> Project: Solr
> Issue Type: Bug
>Affects Versions: 1.3
>Reporter: Henri Biestro
>Assignee: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.3
>
>
> Exposing them precludes being ever able to fill the CoreDescriptor with
> property expressions.
> Since a 'public' method can not be removed easily, this is a future problem.
> Besides, as is, their is no reason for them to be public.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
Re: 1.3 status
On Mon, Aug 25, 2008 at 8:23 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote: > > In Lucene Java, we typically freeze for 10 days, during which only > blockers and documentation patches are allowed to be committed. I'd be fine > w/ 7, but what's 3 more days, right? > Thanks for the info Grant. I've just committed another (small) issue but I promise this will be the last one from my side for 1.3. -- Regards, Shalin Shekhar Mangar.
Re: 1.3 status
OK, so how about we upgrade Lucene again and then we set a freeze date for Wednesday, Aug. 27 of 9 AM EDT (since that's my time zone, and I'm the one calling it :-) ) -Grant On Aug 25, 2008, at 11:20 AM, Shalin Shekhar Mangar wrote: On Mon, Aug 25, 2008 at 8:23 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote: In Lucene Java, we typically freeze for 10 days, during which only blockers and documentation patches are allowed to be committed. I'd be fine w/ 7, but what's 3 more days, right? Thanks for the info Grant. I've just committed another (small) issue but I promise this will be the last one from my side for 1.3. -- Regards, Shalin Shekhar Mangar.
Re: 1.3 status
Grant, if you have time to make the RC today, we could run it until next weekend and have the 1.3 released on Monday. Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message > From: Shalin Shekhar Mangar <[EMAIL PROTECTED]> > To: solr-dev@lucene.apache.org > Sent: Monday, August 25, 2008 11:20:57 AM > Subject: Re: 1.3 status > > On Mon, Aug 25, 2008 at 8:23 PM, Grant Ingersoll wrote: > > > > > In Lucene Java, we typically freeze for 10 days, during which only > > blockers and documentation patches are allowed to be committed. I'd be fine > > w/ 7, but what's 3 more days, right? > > > > Thanks for the info Grant. > > I've just committed another (small) issue but I promise this will be the > last one from my side for 1.3. > > -- > Regards, > Shalin Shekhar Mangar.
[jira] Updated: (SOLR-374) use IndexReader.reopen
[ https://issues.apache.org/jira/browse/SOLR-374?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Otis Gospodnetic updated SOLR-374: -- Fix Version/s: 1.4 > use IndexReader.reopen > -- > > Key: SOLR-374 > URL: https://issues.apache.org/jira/browse/SOLR-374 > Project: Solr > Issue Type: Improvement >Reporter: Yonik Seeley > Fix For: 1.4 > > Attachments: SOLR-374.patch, SOLR-374.patch, SOLR-374.patch, > SOLR-374.patch, SOLR-374.patch > > > Take advantage of IndexReader.reopen(): LUCENE-743 -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: 1.3 status
On Mon, Aug 25, 2008 at 8:55 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote: > OK, so how about we upgrade Lucene again and then we set a freeze date for > Wednesday, Aug. 27 of 9 AM EDT (since that's my time zone, and I'm the one > calling it :-) ) Aren't we going to create a branch for this? If yes, why not upgrade lucene jars and freeze right now and release on 1st September? :-) We can continue to work (and commit) on 1.4 issues on the trunk without stopping our hands. I'm planning to dedicate some time to work on the replication patches this week. -- Regards, Shalin Shekhar Mangar.
Re: 1.3 status
I was thinking we might want a day or two on the new Lucene and also that not everyone is reading this thread immediately, so we need to give them time to react. But, yeah, we can create the branch today, if that's what people want. Yonik, do you want to do the Lucene upgrade (you're getting so good at it) and then we can create the branch? I can tell you now I'm not doing the release over the Labor day weekend, as I plan on minimizing my labor... On Aug 25, 2008, at 11:31 AM, Shalin Shekhar Mangar wrote: On Mon, Aug 25, 2008 at 8:55 PM, Grant Ingersoll <[EMAIL PROTECTED]>wrote: OK, so how about we upgrade Lucene again and then we set a freeze date for Wednesday, Aug. 27 of 9 AM EDT (since that's my time zone, and I'm the one calling it :-) ) Aren't we going to create a branch for this? If yes, why not upgrade lucene jars and freeze right now and release on 1st September? :-) We can continue to work (and commit) on 1.4 issues on the trunk without stopping our hands. I'm planning to dedicate some time to work on the replication patches this week. -- Regards, Shalin Shekhar Mangar.
IndexPartitioning
Just came across http://wiki.apache.org/solr/IndexPartitioning . Does anyone think we still need this idea (vs. MultiCore)? Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch
Package Access Issues / Extending FacetComponent
I'm creating a FacetComponent that is a simple extension of the regular one (I'm creating numeric ranges for some fields). I would like to preserve most of the original functionality, and only override the default behavior for some specific cases. The problem I'm facing is that a lot of the core behavior uses package-restricted classes that I don't have access to from my own jar. The classes are: FieldFacet DistribFieldFacet FacetInfo ShardFacetCount And the ResponseBuilder's _facetInfo member variable. Recently, the ShardResponse class became public for a similar need (http://www.nabble.com/ShardResponse-IllegalAccessError-to18461917.html#a18507845). I looked through its object model, and all the data I need is contained there. I could override just the finishStage method using the ShardResponse data, but it means I'd also have to also re-write all the functionality in the classes listed above. What's the best way for me to proceed? The options I've considered: 1. Copy all those classes into my own package, copy the FacetComponent into my own package, and then override as I intended (there might still be some issues with accessing ResponseBuilder._facetInfo). 2. Re-write the entire component using only the ShardResponse. 3. Make those classes publicly accessible. Thanks. -- View this message in context: http://www.nabble.com/Package-Access-Issues---Extending-FacetComponent-tp19148122p19148122.html Sent from the Solr - Dev mailing list archive at Nabble.com.
Re: 1.3 status
+1 for 1.3 RC. The idea of putting new issues in 1.3.1 has been tossed around a few times on this list in the last few weeks. I'm not sure how other people feel about this, but in my mind, 1.X.Y and 1.X.Z releases should be feature-identical, with later releases only containing bugfixes. If we have a bunch of cool features we want to release shortly, I'd be happy with releasing 1.4 quickly :) -Mike On 25-Aug-08, at 7:30 AM, Shalin Shekhar Mangar wrote: +1 for Lucene upgrade +1 for a release candidate. I think the newer issues can make it to 1.3.1 easily. We don't need to halt 1.3 for them. A general question -- how long does a Release Candidate phase lasts? On Mon, Aug 25, 2008 at 7:51 PM, Otis Gospodnetic < [EMAIL PROTECTED]> wrote: +1 for Lucene upgrade +1 for a release (I *think* none of the recent SOLR-7** issues have to go in 1.3) Otis -- Sematext -- http://sematext.com/ -- Lucene - Solr - Nutch - Original Message From: Erik Hatcher <[EMAIL PROTECTED]> To: solr-dev@lucene.apache.org Sent: Monday, August 25, 2008 10:06:46 AM Subject: Re: 1.3 status On Aug 25, 2008, at 9:48 AM, Yonik Seeley wrote: Given that there are backward compat concerns with https://issues.apache.org/jira/browse/LUCENE-1142 perhaps we should update Lucene again before a release? +1 Erik -- Regards, Shalin Shekhar Mangar.
Re: Solr nightly build failure
: Because the maven artifacts are part of packaging for release. People who : don't want them can run "create-package", or we could call it core-package. I The problem i have is that up until now, anyone that wanted to checkou the source and build it could run "ant package" and get a nice zip file and a tar ball ... now people who do that get an error that they need maven extensions to ant -- that shouldn't required if they don't care about maven. Telling people to run "ant create-package" instead isn't that hard is suppose, but if that's the way things are going to be then, let's change "ant usage" to reflect reality. I really just don't really understand why "ant package" needed to change at all? Why not just add a "maven-packages" target that depends on "package" for people that want maven packaging? : just thought for release purposes it's easier to just call one target that has : it all. If that's the main reason for setting things up this way, i'd rather add a new "release" target then modify the "package" target ... there's no reason to break things for existing users who don't care about maven. : The bigger ? in my mind is why do we have two different nightly builds? : Hudson and crontab. well in theory the crontab shell script is the "sanctioned" nightly builds that get copied to people.apache.org and are linked to from the website ... the Hudson stuff was initially setup as an experiment. We've discussed at least once in the past eliminating the crontab based builds, but they've caught problems just like this one before (ie: slightly different environments getting idfferent problems because the build files get tweaked) -Hoss
Re: 1.3 status
: Aren't we going to create a branch for this? If yes, why not upgrade lucene : jars and freeze right now and release on 1st September? :-) release branches are created, but durring the days leading up to a release it's a good idea to refrain from doing too much work on the trunk: 1) it makes it more complicated for people to merge bug fixes from the trunk to the release branch (or viceversa) 2) it creates noise that can distract/confuse people about what has been committed where 3) ideally people should be focused on improving documentation and fixing build for the impeding release, not getting too far ahead of ourselves with the next release. if people really want to work on future features that's fine, but we tend to work mainly with patches anyway -- waiting a few days to commit a new feature patch to the trunk isn't that big of a deal. -Hoss
Re: 1.3 status
: The idea of putting new issues in 1.3.1 has been tossed around a few times on : this list in the last few weeks. I'm not sure how other people feel about : this, but in my mind, 1.X.Y and 1.X.Z releases should be feature-identical, : with later releases only containing bugfixes. If we have a bunch of cool Correct. If a 1.3.1 release exists it should be 1.3 with bug fixes - no new features. There's nothing to stop a 1.4 release with new features from coming out a week after 1.3 if people think it's warranted. -Hoss
Re: 1.3 status
: OK, so how about we upgrade Lucene again and then we set a freeze date for : Wednesday, Aug. 27 of 9 AM EDT (since that's my time zone, and I'm the one : calling it :-) ) Grant, Just to clarify. you want to: 1) freeze the *trunk* on the 27th 2) focus on bug fixes and documentation improvements on the trunk for 7-10 days, 3) create a 1.3 release branch at some point ~Sep3-6 4) start reviewing/voting on release candidates at the point where #1 adn #2 corrispond to the "Code Freeze" and #3 and #4 corrispond to "Making a release" of this wiki page... http://wiki.apache.org/solr/HowToRelease ..correct? -Hoss
Re: 1.3 status
Yonik Seeley wrote: > Given that there are backward compat concerns with > https://issues.apache.org/jira/browse/LUCENE-1142 > perhaps we should update Lucene again before a release? > As the maintainer of the Debian solr package, I would be interested to know whether solr 1.3 will be compatible the the upcoming Lucene 2.4? Jan-Pascal signature.asc Description: OpenPGP digital signature
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625541#action_12625541 ] Henri Biestro commented on SOLR-725: Otis, this does not hold releasing 1.3; I'm glad solr-724 got solved. I just wish it will be easier (& faster) to release 1.3.1. :-) Shalin, I'll do my best about solr-723; but again, this should not hold releasing 1.3. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
Re: Solr nightly build failure
On Aug 25, 2008, at 1:50 PM, Chris Hostetter wrote: : Because the maven artifacts are part of packaging for release. People who : don't want them can run "create-package", or we could call it core- package. I The problem i have is that up until now, anyone that wanted to checkou the source and build it could run "ant package" and get a nice zip file and a tar ball ... now people who do that get an error that they need maven extensions to ant -- that shouldn't required if they don't care about maven. Telling people to run "ant create-package" instead isn't that hard is suppose, but if that's the way things are going to be then, let's change "ant usage" to reflect reality. I really just don't really understand why "ant package" needed to change at all? Why not just add a "maven-packages" target that depends on "package" for people that want maven packaging? I figured the auto build systems were already calling "package", thus, I wanted them to work and do the lifting of building the Maven packages as well. Package was what was being called on Hudson, and presumably nightly, too, so I figured it was a good thing to keep it the same, lest I have to go change all of those too. : just thought for release purposes it's easier to just call one target that has : it all. If that's the main reason for setting things up this way, i'd rather add a new "release" target then modify the "package" target ... there's no reason to break things for existing users who don't care about maven. I don't care either way, as long as Hudson and nightly work. Go for it, if you want to change all the touch points that call package. -Grant
Re: 1.3 status
On Aug 25, 2008, at 2:18 PM, Chris Hostetter wrote: : OK, so how about we upgrade Lucene again and then we set a freeze date for : Wednesday, Aug. 27 of 9 AM EDT (since that's my time zone, and I'm the one : calling it :-) ) Grant, Just to clarify. you want to: 1) freeze the *trunk* on the 27th 2) focus on bug fixes and documentation improvements on the trunk for 7-10 days, 3) create a 1.3 release branch at some point ~Sep3-6 4) start reviewing/voting on release candidates at the point where #1 adn #2 corrispond to the "Code Freeze" and #3 and #4 corrispond to "Making a release" of this wiki page... http://wiki.apache.org/solr/HowToRelease I think in Lucene, we usually branch on freeze, too, and then apply patches to both, if need be, this way trunk can move forward.
Re: IndexPartitioning
On Mon, 25 Aug 2008 09:34:28 -0700 (PDT)
Otis Gospodnetic <[EMAIL PROTECTED]> wrote:
> Just came across http://wiki.apache.org/solr/IndexPartitioning . Does anyone
> think we still need this idea (vs. MultiCore)?
>
interesting - it sounds to me more like shards than multicore, doesn't it? ...
but instead of querying all shards for results, only the shards that are
expected to contain the data we are after are queried. Similar to PostgreSQL's
(and Oracle's + others?) partitions by query.
FWIW, I think it'd be very nice to handle this @ the request handler level,
rather than @ the data import/query stage Obviously, as an alternative
option to the current shards approach, for those cases where we can't (or don't
want to) define the "partitions".
cheers,
B
_
{Beto|Norberto|Numard} Meijome
If you're not part of the solution, you're part of the precipitate.
I speak for myself, not my employer. Contents may be hot. Slippery when wet.
Reading disclaimers makes you go blind. Writing them is worse. You have been
Warned.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625631#action_12625631 ] Shalin Shekhar Mangar commented on SOLR-725: It seems that calling Alias may lead to closing of the old core in the CoreContainer#register method. The old core is closed even if it is aliased to some other name. This is a very dangerous side-effect of Alias and must be remedied. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Commented: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625635#action_12625635 ] Noble Paul commented on SOLR-725: - bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow your logic. You give an example of using core alias My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use ALIAS . The usecase is this. I wish to start core and ensure that it is initialized properly . If it does I wish to replace that with another core . My concern here , * We have added a feature called ALIAS * Nobody has a compelling usecase for that. * Because of this feature some very useful methods are implemented inconsistently. As Yonik says "core should be independent of how it is named" . But as things stand we are removing some commonly useful methods for a feature which does not have a usecase. OK. Now that we already have ALIAS as a feature I propose the following behavior * let the getName() methods remain as is. * An ALIAS *must not* rename a core. It should just add another mapping in the core container. The only command that should change a core's name should be SWAP * An ALIAS command should not succeed if the new name is already registered for another core. * The solr.xml tag must keep the name as the primary name. We can add an extra attribute 'alias' which can take multiple names. This is already discussed in SOLR-350. * UNALIAS command can be added . It can just remove an ALIAS if it exists . But it must not be able to remove the primary name. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniqueness. > h4. SolrCore instance operations > * *load*: makes a SolrCore available for requests > **creates a SolrCore > **registers all SolrCore aliases in the aliases set > **(load = create + register) > * *unload*: removes a core idenitified by one of its aliases > **stops handling the Lucene index > **all SolrCore aliases are removed > * *reload*: recreate the core identified by one of its aliases > * *create*: create a core from a CoreDescriptor > **readies up the Lucene index > * *register*: registers all aliases of a SolrCore > > h4. SolrCore alias operations > * *swap*: swaps 2 aliases > **method: swap > * *alias*: creates 1 alias for a core, potentially unaliasing a > previously used alias > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > * *unalias*: removes 1 alias for a core > **The SolrCore name being an alias, this operation might trigger > a SolrCore rename > -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Issue Comment Edited: (SOLR-725) CoreContainer/CoreDescriptor/SolrCore cleansing
[ https://issues.apache.org/jira/browse/SOLR-725?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625635#action_12625635 ] noble.paul edited comment on SOLR-725 at 8/25/08 10:51 PM: --- bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow your logic. You give an example of using core alias My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use ALIAS . The usecase is this. I wish to start core and ensure that it is initialized properly . If it does I wish to replace that with another core . My concern here , * We have added a feature called ALIAS * Nobody has a compelling usecase for that. * Because of this feature some very useful methods are implemented inconsistently. As Yonik says "core should be independent of how it is named" . But as things stand we are removing some commonly useful methods for a feature which does not have a usecase. OK. Now that we already have ALIAS as a feature I propose the following behavior , * let the getName() methods remain as is. * An ALIAS *must not* rename a core. It should just add another mapping in the core container. The only command that should change a core's name should be SWAP * An ALIAS command *must not* succeed if the new name is already registered for another core. If a user wish to do so UNLOAD that core , or if it is an alias UNALIAS that name before trying this. * The solr.xml tag must keep the name as the primary name. We can add an extra attribute 'alias' which can take multiple names. This is already discussed in SOLR-350. * UNALIAS command can be added . It can just remove an ALIAS if it exists . But it must not be able to remove the primary name. was (Author: noble.paul): bq.Paul - I haven't looked at Henri's patch, but like Henri I also don't follow your logic. You give an example of using core alias My example uses SWAP . SWAP is a indeed a useful feature and SWAP does not use ALIAS . The usecase is this. I wish to start core and ensure that it is initialized properly . If it does I wish to replace that with another core . My concern here , * We have added a feature called ALIAS * Nobody has a compelling usecase for that. * Because of this feature some very useful methods are implemented inconsistently. As Yonik says "core should be independent of how it is named" . But as things stand we are removing some commonly useful methods for a feature which does not have a usecase. OK. Now that we already have ALIAS as a feature I propose the following behavior * let the getName() methods remain as is. * An ALIAS *must not* rename a core. It should just add another mapping in the core container. The only command that should change a core's name should be SWAP * An ALIAS command should not succeed if the new name is already registered for another core. * The solr.xml tag must keep the name as the primary name. We can add an extra attribute 'alias' which can take multiple names. This is already discussed in SOLR-350. * UNALIAS command can be added . It can just remove an ALIAS if it exists . But it must not be able to remove the primary name. > CoreContainer/CoreDescriptor/SolrCore cleansing > --- > > Key: SOLR-725 > URL: https://issues.apache.org/jira/browse/SOLR-725 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.3 >Reporter: Henri Biestro > Attachments: solr-725.patch > > > These 3 classes and the name vs alias handling are somewhat confusing. > The recent SOLR-647 & SOLR-716 have created a bit of a flux. > This issue attemps to clarify the model and the list of operations. > h3. CoreDescriptor: describes the parameters of a SolrCore > h4. Definitions > * has one name > ** The CoreDescriptor name may represent multiple aliases; in that > case, first alias is the SolrCore name > * has one instance directory location > * has one config & schema name > h4. Operations > The class is only a parameter passing facility > h3. SolrCore: manages a Lucene index > h4. Definitions > * has one unique *name* (in the CoreContainer) > **the *name* is used in JMX to identify the core > * has one current set of *aliases* > **the name is the first alias > h4. Name & alias operations > * *get name/aliases*: obvious > * *alias*: adds an alias to this SolrCore > * *unalias*: removes an alias from this SolrCore > * *name*: sets the SolrCore name > **potentially impacts JMX registration > * *rename*: picks a new name from the SolrCore aliases > **triggered when alias name is already in use > h3. CoreContainer: manages all relations between cores & descriptors > h4. Definitions > * has a set of aliases (each of them pointing to one core) > **ensure alias uniquen
