[jira] [Commented] (SOLR-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13599346#comment-13599346
]
Rene Nederhand commented on SOLR-4373:
--
I was the one reporting an issue with the fix, but as it seems I must have made
an error somewhere as I tried really hard to reproduce the error in a brand new
SolrCloud installation, but wasn't able to. Let's call this resolved.
> In multicore, lib directives in solrconfig.xml cause conflict and clobber
> directives from earlier cores
> ---
>
> Key: SOLR-4373
> URL: https://issues.apache.org/jira/browse/SOLR-4373
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 4.1, 4.2
>Reporter: Alexandre Rafalovitch
>Assignee: Hoss Man
> Labels: lib, multicore
> Fix For: 4.2
>
> Attachments: multicore-bug.zip, testscript.sh
>
>
> Having lib directives in the solrconfig.xml files of multiple cores can cause
> problems when using multi-threaded core initialization -- which is the
> default starting with Solr 4.1.
> The problem manifests itself as init errors in the logs related to not being
> able to find classes located in plugin jars, even though earlier log messages
> indicated that those jars had been added to the classpath.
> One work around is to set {{coreLoadThreads="1"}} in your solr.xml file --
> forcing single threaded core initialization. For example...
> {code}
>
>
>
>
>
>
>
> {code}
> (Similar problems may occur if multiple cores are initialized concurrently
> using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (SOLR-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Nederhand updated SOLR-4373:
-
Attachment: testscript.sh
Test script to create a collection, upload/link a config and create two cores.
> In multicore, lib directives in solrconfig.xml cause conflict and clobber
> directives from earlier cores
> ---
>
> Key: SOLR-4373
> URL: https://issues.apache.org/jira/browse/SOLR-4373
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 4.1
>Reporter: Alexandre Rafalovitch
>Priority: Blocker
> Labels: lib, multicore
> Fix For: 4.2, 5.0, 4.1.1
>
> Attachments: multicore-bug.zip, testscript.sh
>
>
> Having lib directives in the solrconfig.xml files of multiple cores can cause
> problems when using multi-threaded core initialization -- which is the
> default starting with Solr 4.1.
> The problem manifests itself as init errors in the logs related to not being
> able to find classes located in plugin jars, even though earlier log messages
> indicated that those jars had been added to the classpath.
> One work around is to set {{coreLoadThreads="1"}} in your solr.xml file --
> forcing single threaded core initialization. For example...
> {code}
>
>
>
>
>
>
>
> {code}
> (Similar problems may occur if multiple cores are initialized concurrently
> using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13590908#comment-13590908
]
Rene Nederhand commented on SOLR-4373:
--
I'm still experiencing the same problems (rev 1450937): Libraries cannot be
found.
Moreover, the workaround by adding {{coreLoadThreads="1"}} to solr.xml does not
work in SolrCloud. I get: "SolrCloud requires a value of at least 2 in solr.xml
for coreLoadThreads".
One additional observation: The first time I create a core it fails, however
the second time it succeeds. Does anyone knows why it happens? FYI: I am
attaching the test script I am using to upload, link the config and create the
cores.
> In multicore, lib directives in solrconfig.xml cause conflict and clobber
> directives from earlier cores
> ---
>
> Key: SOLR-4373
> URL: https://issues.apache.org/jira/browse/SOLR-4373
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 4.1
>Reporter: Alexandre Rafalovitch
>Priority: Blocker
> Labels: lib, multicore
> Fix For: 4.2, 5.0, 4.1.1
>
> Attachments: multicore-bug.zip
>
>
> Having lib directives in the solrconfig.xml files of multiple cores can cause
> problems when using multi-threaded core initialization -- which is the
> default starting with Solr 4.1.
> The problem manifests itself as init errors in the logs related to not being
> able to find classes located in plugin jars, even though earlier log messages
> indicated that those jars had been added to the classpath.
> One work around is to set {{coreLoadThreads="1"}} in your solr.xml file --
> forcing single threaded core initialization. For example...
> {code}
>
>
>
>
>
>
>
> {code}
> (Similar problems may occur if multiple cores are initialized concurrently
> using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[
https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13588855#comment-13588855
]
Rene Nederhand commented on LUCENE-2899:
New patch for both trunk and 4.1 stable. Tested on revision 1450998.
{code}
ant compile
cd solr/contrib/src/test-files/training
sh bin/trainall.sh
cd ../../../../../../solr
ant example test-contrib
{code}
Hope this helps more people in testing OpenNLP integration with Solr.
TODO:
* Implementing dev-tools
* Include references to javadocs
> Add OpenNLP Analysis capabilities as a module
> -
>
> Key: LUCENE-2899
> URL: https://issues.apache.org/jira/browse/LUCENE-2899
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/analysis
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch,
> LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch,
> LUCENE-2899-RJN.patch, OpenNLPFilter.java, OpenNLPTokenizer.java,
> opennlp_trunk.patch
>
>
> Now that OpenNLP is an ASF project and has a nice license, it would be nice
> to have a submodule (under analysis) that exposed capabilities for it. Drew
> Farris, Tom Morton and I have code that does:
> * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it
> would have to change slightly to buffer tokens)
> * NamedEntity recognition as a TokenFilter
> We are also planning a Tokenizer/TokenFilter that can put parts of speech as
> either payloads (PartOfSpeechAttribute?) on a token or at the same position.
> I'd propose it go under:
> modules/analysis/opennlp
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Updated] (LUCENE-2899) Add OpenNLP Analysis capabilities as a module
[
https://issues.apache.org/jira/browse/LUCENE-2899?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rene Nederhand updated LUCENE-2899:
---
Attachment: LUCENE-2899-RJN.patch
New patch for both trunk and 4.1 stable. Tested on revision 1450998.
{code}
ant compile
cd solr/contrib/src/test-files/training
sh bin/trainall.sh
cd ../../../../../../solr
ant example test-contrib
{code}
Hope this helps more people in testing OpenNLP integration with Solr.
TODO:
* Implementing dev-tools
* Include references to javadocs
> Add OpenNLP Analysis capabilities as a module
> -
>
> Key: LUCENE-2899
> URL: https://issues.apache.org/jira/browse/LUCENE-2899
> Project: Lucene - Core
> Issue Type: New Feature
> Components: modules/analysis
>Reporter: Grant Ingersoll
>Assignee: Grant Ingersoll
>Priority: Minor
> Fix For: 4.2, 5.0
>
> Attachments: LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch,
> LUCENE-2899.patch, LUCENE-2899.patch, LUCENE-2899.patch,
> LUCENE-2899-RJN.patch, OpenNLPFilter.java, OpenNLPTokenizer.java,
> opennlp_trunk.patch
>
>
> Now that OpenNLP is an ASF project and has a nice license, it would be nice
> to have a submodule (under analysis) that exposed capabilities for it. Drew
> Farris, Tom Morton and I have code that does:
> * Sentence Detection as a Tokenizer (could also be a TokenFilter, although it
> would have to change slightly to buffer tokens)
> * NamedEntity recognition as a TokenFilter
> We are also planning a Tokenizer/TokenFilter that can put parts of speech as
> either payloads (PartOfSpeechAttribute?) on a token or at the same position.
> I'd propose it go under:
> modules/analysis/opennlp
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587162#comment-13587162
]
Rene Nederhand commented on SOLR-4373:
--
Sorry, I thought this would be clear from the readme. This is what I do (in
Linux):
svn co http://svn.apache.org/repos/asf/lucene/dev/trunk/
lucene-trunkcd lucene_trunk*# Apply patches (e.g. patch -p0 <
SOLR-3808-4.1-1.patch)*# It might be necessary to to a "ant
ivy-bootstrap" first# Based on ant 1.8.4
ant compilecd solr
ant example
ant dist
On Tue, Feb 26, 2013 at 3:24 PM, Alexandre Rafalovitch (JIRA) <
> In multicore, lib directives in solrconfig.xml cause conflict and clobber
> directives from earlier cores
> ---
>
> Key: SOLR-4373
> URL: https://issues.apache.org/jira/browse/SOLR-4373
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 4.1
>Reporter: Alexandre Rafalovitch
>Priority: Blocker
> Labels: lib, multicore
> Fix For: 4.2, 5.0, 4.1.1
>
> Attachments: multicore-bug.zip
>
>
> Having lib directives in the solrconfig.xml files of multiple cores can cause
> problems when using multi-threaded core initialization -- which is the
> default starting with Solr 4.1.
> The problem manifests itself as init errors in the logs related to not being
> able to find classes located in plugin jars, even though earlier log messages
> indicated that those jars had been added to the classpath.
> One work around is to set {{coreLoadThreads="1"}} in your solr.xml file --
> forcing single threaded core initialization. For example...
> {code}
>
>
>
>
>
>
>
> {code}
> (Similar problems may occur if multiple cores are initialized concurrently
> using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Commented] (SOLR-4373) In multicore, lib directives in solrconfig.xml cause conflict and clobber directives from earlier cores
[
https://issues.apache.org/jira/browse/SOLR-4373?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13587152#comment-13587152
]
Rene Nederhand commented on SOLR-4373:
--
You have to do an "ant example" in the solr directory.
Glad this problem seems to be solved. This bug already cost me a lot of
hours...
On Tue, Feb 26, 2013 at 2:58 PM, Alexandre Rafalovitch (JIRA) <
> In multicore, lib directives in solrconfig.xml cause conflict and clobber
> directives from earlier cores
> ---
>
> Key: SOLR-4373
> URL: https://issues.apache.org/jira/browse/SOLR-4373
> Project: Solr
> Issue Type: Bug
> Components: multicore
>Affects Versions: 4.1
>Reporter: Alexandre Rafalovitch
>Priority: Blocker
> Labels: lib, multicore
> Fix For: 4.2, 5.0, 4.1.1
>
> Attachments: multicore-bug.zip
>
>
> Having lib directives in the solrconfig.xml files of multiple cores can cause
> problems when using multi-threaded core initialization -- which is the
> default starting with Solr 4.1.
> The problem manifests itself as init errors in the logs related to not being
> able to find classes located in plugin jars, even though earlier log messages
> indicated that those jars had been added to the classpath.
> One work around is to set {{coreLoadThreads="1"}} in your solr.xml file --
> forcing single threaded core initialization. For example...
> {code}
>
>
>
>
>
>
>
> {code}
> (Similar problems may occur if multiple cores are initialized concurrently
> using the /admin/cores handler)
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
