[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/26/08 12:04 AM: --- 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. * SolrQueryRequest should have a method to let handlers know through which alias this request is made 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 *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. > 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
[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/26/08 12:07 AM: --- 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 * Whose usecases are not ver clear * 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 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 (use UNLOAD to do that). * SolrQueryRequest should have a method to let handlers know through which alias this request is made 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 *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. * SolrQueryRequest should have a method to let handlers know through which alias this request is made > 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*: pi
[jira] Created: (SOLR-726) driver and datasources are not loaded using the multicore lib aware SolrResourceLoader
driver and datasources are not loaded using the multicore lib aware SolrResourceLoader -- Key: SOLR-726 URL: https://issues.apache.org/jira/browse/SOLR-726 Project: Solr Issue Type: Bug Components: contrib - DataImportHandler Affects Versions: 1.3 Reporter: Walter Ferrara Priority: Minor see http://www.nabble.com/dataimporthandler-and-mysql-connector-jar-td19146229.html The jar containing the (jdbc) driver have to be present in the java classpath. Putting it in coreX/lib or in the shared lib dir of a multicore solr doesn't work -- 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: 19.239 sec [junit] Running org.apache.solr.ConvertedLegacyTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 9.086 sec [junit] Running org.apache.solr.DisMaxRequestHandlerTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 5.62 sec [junit] Running org.apache.solr.EchoParamsTest [junit] Tests run: 4, Failures: 0, Errors: 0, Time elapsed: 2.897 sec [junit] Running org.apache.solr.OutputWriterTest [junit] Tests run: 3, Failures: 0, Errors: 0, Time elapsed: 3.612 sec [junit] Running org.apache.solr.SampleTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 2.319 sec [junit] Running org.apache.solr.SolrInfoMBeanTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.975 sec [junit] Running org.apache.solr.TestDistributedSearch [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 27.213 sec [junit] 2008-08-26 08:08:17.755::INFO: Shutdown hook executing [junit] 2008-08-26 08:08:17.755::INFO: Shutdown hook complete [junit] 2008-08-26 08:08:18.757::INFO: Shutdown hook complete [junit] 2008-08-26 08:08:19.767::INFO: Shutdown hook complete [junit] 2008-08-26 08:08:20.777::INFO: Shutdown hook complete [junit] 2008-08-26 08:08:21.787::INFO: Shutdown hook complete [junit] 2008-08-26 08:08:22.796::INFO: Shutdown hook complete [junit] 2008-08-26 08:08:23.806::INFO: Shutdown hook complete [junit] 2008-08-26 08:08:24.816::INFO: Shutdown hook complete [junit] 2008-08-26 08:08:25.826::INFO: Shutdown hook complete [junit] Running org.apache.solr.analysis.EnglishPorterFilterFactoryTest [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.202 sec [junit] Running org.apache.solr.analysis.HTMLStripReaderTest [junit] Tests run: 9, Failures: 0, Errors: 0, Time elapsed: 1.01 sec [junit] Running org.apache.solr.analysis.LengthFilterTest [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.991 sec [junit] Running org.apache.solr.analysis.TestBufferedTokenStream [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.076 sec [junit] Running org.apache.solr.analysis.TestCapitalizationFilter [junit] Tests run: 2, Failures: 0, Errors: 0, Time elapsed: 1.537 sec [junit] Running org.apache.solr.analysis.TestHyphenatedWordsFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.925 sec [junit] Running org.apache.solr.analysis.TestKeepWordFilter [junit] Tests run: 1, Failures: 0, Errors: 0, Time elapsed: 0.985 sec [junit] Running org.apache.solr.analysis.TestPatternReplaceFilter [junit] Tests run: 5, Failures:
Re: CoreContainer can store the appcontext, host and port of the Solr application
Sure. Henri. I'll raise an issue and we can decide as to where to keep it On Mon, Aug 25, 2008 at 6:28 PM, Henrib <[EMAIL PROTECTED]> wrote: > > > > 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. > > -- --Noble Paul
[jira] Created: (SOLR-727) appcontext, host and port of the Solr application must be available through API
appcontext, host and port of the Solr application must be available through API --- Key: SOLR-727 URL: https://issues.apache.org/jira/browse/SOLR-727 Project: Solr Issue Type: New Feature Reporter: Noble Paul This is a part of requirement for SOLR-561 . It will be a very nice feature to have the admin console of the master show details of the slaves also. To do so The master must know about the slaves. The slaves may be able to register themselves with master but the slaves do not know the port number and the context in which the app is deployed. The CoreContainer (or any other suitable place) can keep this information with itself so any handler can consume this. Other than the port number everything else is available at the startup time.The port number can be obtained soon after the first request is served by the slave . -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
[jira] Created: (SOLR-728) Add synchronization to avoid race condition of multiple imports working concurrently
Add synchronization to avoid race condition of multiple imports working concurrently Key: SOLR-728 URL: https://issues.apache.org/jira/browse/SOLR-728 Project: Solr Issue Type: Improvement Components: contrib - DataImportHandler Affects Versions: 1.3 Reporter: Walter Ferrara Priority: Minor see http://www.nabble.com/dataimporthandler-and-multiple-delta-import-td19160129.html DataimportHandler import command should check if status is not idle, to avoid race conditions -- 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-723) SolrCore & aliasing/swapping may lead to confusing JMX
[ https://issues.apache.org/jira/browse/SOLR-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625719#action_12625719 ] henrib edited comment on SOLR-723 at 8/26/08 6:06 AM: - Yonik's comment in solr-725 makes an analogy between name/aliases and the SolrCore that's close to what hard-links are to inodes. What if we were to consider the 'inode' as the sole think that really uniquely identifies a SolrCore, that is it's *dataDir*? The SolrCore *name* would not be used for that purpose and would only happen to be the first alias (as it stands now). This would allow solving this issue by changing how we register a core into JMX (with its relative path to the solr.solr.home dir or something close to that) and have no swapping, etc. Just a thought. was (Author: henrib): Yonik's comment in solr-725 makes an analogy between name/aliases and the SolrCore that's close to what hard-links are to inodes. What if we were to consider the 'inode' as the sole think that really uniquely identifies a SolrCore, that is it's dataDir? The SolrCore *name* would not be used for that purpose and would only happen to be the first alias (as it stands now). This would allow solving this issue by changing how we register a core into JMX (with its relative path to the solr.solr.home dir or something close to that) and have no swapping, etc. Just a thought. > 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.
[jira] Commented: (SOLR-723) SolrCore & aliasing/swapping may lead to confusing JMX
[ https://issues.apache.org/jira/browse/SOLR-723?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625719#action_12625719 ] Henri Biestro commented on SOLR-723: Yonik's comment in solr-725 makes an analogy between name/aliases and the SolrCore that's close to what hard-links are to inodes. What if we were to consider the 'inode' as the sole think that really uniquely identifies a SolrCore, that is it's dataDir? The SolrCore *name* would not be used for that purpose and would only happen to be the first alias (as it stands now). This would allow solving this issue by changing how we register a core into JMX (with its relative path to the solr.solr.home dir or something close to that) and have no swapping, etc. Just a thought. > 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.
[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=12625805#action_12625805
]
Henri Biestro commented on SOLR-725:
Shalin -
We decref the counter appropriately (registerNotSynchronized does not do it) or
I just dont see the issue so I 'll assume that what bothers you is that
unaliasing a core should not have the potential effect of closing it.
If we use Yonik's model, there is no reason not to; the model is akin to the
inode / hard-link model on Unix. The inode in our case is the Lucene index (the
dataDir, managed by the SolrCore) - and the aliases are the hardlinks. If you
remove all links (unalias all aliases), the inode (of the Lucene index) goes
away. Even if the unlink (unalias) is the side effect of another 'ln' (alias).
A symbolic link model - as Paul proposes - is a different one.
I don't get yet what the hard-link/Yonik's model problem is which I'd find
useful to understand .
Paul -
bq. But as things stand we are removing some commonly useful methods
Which ones? Is it something that impacts solr-561 somehow?
Btw, your example started using the alias *feature* ,( not the alias
*command*), creating a core with name 'version-3.0' and alias 'dev'
(*1-create('version-3.0,dev') *); thus the difficulty to get your previous
point.
> 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=12625809#action_12625809 ] Shalin Shekhar Mangar commented on SOLR-725: bq. We decref the counter appropriately (registerNotSynchronized does not do it) Ah right. I forgot that the core is ref counted. I saw the call to close and assumed it will be closed immediately. Sorry about that. > 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-42) Highlighting problems with HTMLStripWhitespaceTokenizerFactory
[
https://issues.apache.org/jira/browse/SOLR-42?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625835#action_12625835
]
Jim Murphy commented on SOLR-42:
I've tracked down some background info on this issue - at least the way it was
affecting me. I could care less about highlighting - I'm using the
HTMLStripWhitespaceTokenizerFactory during indexing to tokenize blog content -
which obviously contains lots of html.
The pathological case I've found with our input document set is:
Content contains a malformed xml processing instruction in the first "page" of
the buffer that contains more than one page of data.
It seems this is a fairly common (maybe MS Word XML?) form of invalid HTML.
Commonly it looks like this:
...valid html..valid html...
Notice the PI starts with "') {
next();
return MATCH;
} else if (ch==-1) {
return MISMATCH;
}
}
return MISMATCH;
}
The demoralizing part is the special treatment (readAheadLimitMinus1) isn't
enough. There is actually a "over read" by 2 chars.
The IOException - Invalid Mark happens when readProcessingInstruction() retuns
(a mismatch because the entire buffer is read without finding the close PI) and
restoreState(); is called to reset the marks - which fails.
If I tweak readAheadLimitMinus1 like this
readAheadLimitMinus1 -= 2
So maybe the variable should be readAheadLimitMinus3 ;)
then the buffer limits are preserved and the exception isn't found, parsing
proceedes as expected.
Jim
> Highlighting problems with HTMLStripWhitespaceTokenizerFactory
> --
>
> Key: SOLR-42
> URL: https://issues.apache.org/jira/browse/SOLR-42
> Project: Solr
> Issue Type: Bug
> Components: highlighter
>Reporter: Andrew May
>Assignee: Grant Ingersoll
>Priority: Minor
> Attachments: htmlStripReaderTest.html, HTMLStripReaderTest.java,
> HtmlStripReaderTestXmlProcessing.patch,
> HtmlStripReaderTestXmlProcessing.patch, SOLR-42.patch, SOLR-42.patch,
> SOLR-42.patch, SOLR-42.patch, TokenPrinter.java
>
>
> Indexing content that contains HTML markup, causes problems with highlighting
> if the HTMLStripWhitespaceTokenizerFactory is used (to prevent the tag names
> from being searchable).
> Example title field:
> 40Ar/39Ar laserprobe dating of mylonitic fabrics in a
> polyorogenic terrane of NW Iberia
> Searching for title:fabrics with highlighting on, the highlighted version has
> the tags in the wrong place - 22 characters to the left of where they
> should be (i.e. the sum of the lengths of the tags).
> Response from Yonik on the solr-user mailing-list:
> HTMLStripWhitespaceTokenizerFactory works in two phases...
> HTMLStripReader removes the HTML and passes the result to
> WhitespaceTokenizer... at that point, Tokens are generated, but the
> offsets will correspond to the text after HTML removal, not before.
> I did it this way so that HTMLStripReader could go before any
> tokenizer (like StandardTokenizer).
> Can you open a JIRA bug for this? The fix would be a special version
> of HTMLStripReader integrated with a WhitespaceTokenizer to keep
> offsets correct.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-243) Create a hook to allow custom code to create custom IndexReaders
[
https://issues.apache.org/jira/browse/SOLR-243?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Mark Miller updated SOLR-243:
-
Attachment: SOLR-243.patch
Okay, I am after SOLR-465, but since this guy hovers around it, so:
New patch with a test to be sure the config / alt factory is indeed used.
Factory class loaded in SolrCore now with the pluginloader - added a new
loadSingle method. SolrIndexConfig really doesn't seem like the right place
for that method that was there anyway...
So, in pushing SOLR-465, I'd like to do things pretty much as is over there
(except use the pluginloader stuff) just before loading the reader factory, so
that the correct Directory imp can be passed to the getReader method. So
comments to how this is done here will direct what I attempt there.
Thoughts? Pick away please, I'd like to help out wrapping this and 465 soon.
> Create a hook to allow custom code to create custom IndexReaders
>
>
> Key: SOLR-243
> URL: https://issues.apache.org/jira/browse/SOLR-243
> Project: Solr
> Issue Type: Improvement
> Components: search
> Environment: Solr core
>Reporter: John Wang
>Assignee: Hoss Man
> Attachments: indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch, indexReaderFactory.patch, indexReaderFactory.patch,
> indexReaderFactory.patch, indexReaderFactory.patch, SOLR-243.patch
>
>
> I have a customized IndexReader and I want to write a Solr plugin to use my
> derived IndexReader implementation. Currently IndexReader instantiation is
> hard coded to be:
> IndexReader.open(path)
> It would be really useful if this is done thru a plugable factory that can be
> configured, e.g. IndexReaderFactory
> interface IndexReaderFactory{
> IndexReader newReader(String name,String path);
> }
> the default implementation would just return: IndexReader.open(path)
> And in the newSearcher and getSearcher methods in SolrCore class can call the
> current factory implementation to get the IndexReader instance and then build
> the SolrIndexSearcher by passing in the reader.
> It would be really nice to add this improvement soon (This seems to be a
> trivial addition) as our project really depends on this.
> Thanks
> -John
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-722) CoreContainer.reload should make core aliases point to reloaded core
[ https://issues.apache.org/jira/browse/SOLR-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley updated SOLR-722: -- Attachment: SOLR-722.patch Here's a patch that fixes this reload issue. > 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 > Attachments: SOLR-722.patch > > > 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] Resolved: (SOLR-707) DocIterator doesn't support remove(); should throw UnsupportedOperationException
[ https://issues.apache.org/jira/browse/SOLR-707?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Yonik Seeley resolved SOLR-707. --- Resolution: Fixed Fix Version/s: 1.3 simple enough :-) committed. > DocIterator doesn't support remove(); should throw > UnsupportedOperationException > > > Key: SOLR-707 > URL: https://issues.apache.org/jira/browse/SOLR-707 > Project: Solr > Issue Type: Bug > Components: search >Affects Versions: 1.3 >Reporter: Sean Timm >Assignee: Otis Gospodnetic >Priority: Trivial > Fix For: 1.3 > > Attachments: SOLR-707.patch > > > In DocSlice, DocIterator doesn't support the optional remove operation. > According to the Iterator Javadocs, remove should throw an > UnsupportedOperationException in this case rather than be a no-op. -- 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=12625976#action_12625976 ] noble.paul edited comment on SOLR-725 at 8/26/08 10:28 PM: --- bq.Which ones? Is it something that impacts solr-561 somehow? Sorry for not being clear. The widely used methods getName() in SolrCore and CoreDescriptor is what I am referring to . The symlink method is least invasive . The reason being , getName() is far more useful than the alias feature itself (think of JMX cores are identified by name. and there are more places ) . Using this approach we get all the benefits of alias and we lose nothing. Moreover the implementation is easy was (Author: noble.paul): bq.Which ones? Is it something that impacts solr-561 somehow? Sorry for not being clear. The widely used methods getName() in SolrCore and CoreDESCRIPTORis what I am referring to . The symlink method is least invasive . The reason being , getName() is far more useful than the alias feature itself (think of JMX cores are identified by name. and there are more places ) . Using this approach we get all the benefits of alias and we lose nothing. Moreover the implementation is easy > 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=12625976#action_12625976 ] Noble Paul commented on SOLR-725: - bq.Which ones? Is it something that impacts solr-561 somehow? Sorry for not being clear. The widely used methods getName() in SolrCore and CoreDESCRIPTORis what I am referring to . The symlink method is least invasive . The reason being , getName() is far more useful than the alias feature itself (think of JMX cores are identified by name. and there are more places ) . Using this approach we get all the benefits of alias and we lose nothing. Moreover the implementation is easy > 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] Created: (SOLR-729) Context.getDataSource(String) gives wrong DataSource instance
Context.getDataSource(String) gives wrong DataSource instance
-
Key: SOLR-729
URL: https://issues.apache.org/jira/browse/SOLR-729
Project: Solr
Issue Type: Bug
Components: contrib - DataImportHandler
Affects Versions: 1.3
Reporter: Shalin Shekhar Mangar
Priority: Minor
Fix For: 1.4
The default implementation of Context -- ContextImpl#getDataSource(String)
method does not use the String argument and returns the current entity's data
source. The javadoc for this method in Context is also inconsistent.
{code}
/**
* Gets a new DataSource instance with a name.
*
* @param name Name of the dataSource as defined in the dataSource tag
* @return a new DataSource instance as configured for the named entity
* @see org.apache.solr.handler.dataimport.DataSource
*/
public abstract DataSource getDataSource(String name);
{code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-729) Context.getDataSource(String) gives wrong DataSource instance
[
https://issues.apache.org/jira/browse/SOLR-729?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Noble Paul updated SOLR-729:
Attachment: SOLR-729.patch
fixes this issue
> Context.getDataSource(String) gives wrong DataSource instance
> -
>
> Key: SOLR-729
> URL: https://issues.apache.org/jira/browse/SOLR-729
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-729.patch
>
>
> The default implementation of Context -- ContextImpl#getDataSource(String)
> method does not use the String argument and returns the current entity's data
> source. The javadoc for this method in Context is also inconsistent.
> {code}
> /**
>* Gets a new DataSource instance with a name.
>*
>* @param name Name of the dataSource as defined in the dataSource tag
>* @return a new DataSource instance as configured for the named entity
>* @see org.apache.solr.handler.dataimport.DataSource
>*/
> public abstract DataSource getDataSource(String name);
> {code}
--
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-729) Context.getDataSource(String) gives wrong DataSource instance
[
https://issues.apache.org/jira/browse/SOLR-729?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12625980#action_12625980
]
noble.paul edited comment on SOLR-729 at 8/26/08 11:21 PM:
---
the javadoc itself was wrong
fixes this issue
was (Author: noble.paul):
fixes this issue
> Context.getDataSource(String) gives wrong DataSource instance
> -
>
> Key: SOLR-729
> URL: https://issues.apache.org/jira/browse/SOLR-729
> Project: Solr
> Issue Type: Bug
> Components: contrib - DataImportHandler
>Affects Versions: 1.3
>Reporter: Shalin Shekhar Mangar
>Priority: Minor
> Fix For: 1.4
>
> Attachments: SOLR-729.patch
>
>
> The default implementation of Context -- ContextImpl#getDataSource(String)
> method does not use the String argument and returns the current entity's data
> source. The javadoc for this method in Context is also inconsistent.
> {code}
> /**
>* Gets a new DataSource instance with a name.
>*
>* @param name Name of the dataSource as defined in the dataSource tag
>* @return a new DataSource instance as configured for the named entity
>* @see org.apache.solr.handler.dataimport.DataSource
>*/
> public abstract DataSource getDataSource(String name);
> {code}
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (SOLR-658) Allow Solr to load index from arbitrary directory in dataDir and Commit point
[ https://issues.apache.org/jira/browse/SOLR-658?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Shalin Shekhar Mangar updated SOLR-658: --- Attachment: SOLR-658.patch This is cut out of the SOLR-561 patch supports loading index from an arbitrary directory. *Changes* # A new method SolrCore#getNewIndexDir() is introduced which tries to read the latest indexDir from index.properties file. If that file is not present the default value (dataDir + "index/") # SolrIndexSearcher now stores the path (indexDir) on which it is opened and has a getter for it. # When SolrCore#getIndexDir() is called, it gives the current searcher's index directory, failing which the default value is given # SolrIndexSearcher is always created with getNewIndexDir() and UpdateHandler also uses getNewIndexDir() to open IndexWriter instances. TODO: * Add a test * Add feature for loading arbitrary commit point. > Allow Solr to load index from arbitrary directory in dataDir and Commit point > - > > Key: SOLR-658 > URL: https://issues.apache.org/jira/browse/SOLR-658 > Project: Solr > Issue Type: Improvement >Affects Versions: 1.4 >Reporter: Noble Paul >Assignee: Shalin Shekhar Mangar > Fix For: 1.4 > > Attachments: SOLR-658.patch > > > This is a requirement for java based Solr replication > Usecase for arbitrary index directory: > if the slave has a corrupted index and the filesystem does not allow > overwriting files in use (NTFS) replication will fail. The solution is to > copy the index from master to an alternate directory on slave and load > indexreader/indexwriter from this alternate directory. > Usecase for arbitrary commitpoint : > Replication can also provide rollback feature . The rollback should be able > to mention a comitpoint /generation so that rollback is possible. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.
