[jira] [Comment Edited] (SOLR-9867) The schemaless example can not be started after being stopped.
[ https://issues.apache.org/jira/browse/SOLR-9867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15833063#comment-15833063 ] Mark Miller edited comment on SOLR-9867 at 1/21/17 5:10 PM: Yeah, and that may work for some, but now there is a race where it won't work in many cases, and it also means we have added a race to many scripting cases similar to our start script issue - if you start Solr and start trying to interact with a core in a script, it will depend on timing how successful you are without introducing retry code. Anyway, I'll fix this soon, I've just been busy. was (Author: markrmil...@gmail.com): Yeah, and that may work for some, but now there is a race where it won't work in many cases, and it also means we have added a race to many scripting cases similar to our start script issue - if you start Solr and start trying to interact with a core in a script, it will depend on timing how successful you are with introducing retry code. Anyway, I'll fix this soon, I've just been busy. > The schemaless example can not be started after being stopped. > -- > > Key: SOLR-9867 > URL: https://issues.apache.org/jira/browse/SOLR-9867 > Project: Solr > Issue Type: Bug > Security Level: Public(Default Security Level. Issues are Public) >Reporter: Mark Miller > Fix For: master (7.0), 6.4 > > Attachments: SOLR-9867.patch, SOLR-9867.patch > > > I'm having trouble when I start up the schemaless example after shutting down. > I first tracked this down to the fact that the run example tool is getting an > error when it tries to create the SolrCore (again, it already exists) and so > it deletes the cores instance dir which leads to tlog and index lock errors > in Solr. > The reason it seems to be trying to create the core when it already exists is > that the run example tool uses a core status call to check existence and > because the core is loading, we don't consider it as existing. I added a > check to look for core.properties. > That seemed to let me start up, but my first requests failed because the core > was still loading. It appears CoreContainer#getCore is supposed to be > blocking so you don't have this problem, but there must be an issue, because > it is not blocking. -- This message was sent by Atlassian JIRA (v6.3.4#6332) - To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9867) The schemaless example can not be started after being stopped.
[
https://issues.apache.org/jira/browse/SOLR-9867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15810626#comment-15810626
]
Varun Thacker edited comment on SOLR-9867 at 1/9/17 4:15 AM:
-
I tried out the patch against master and I get this error
{code}
[master] ~/apache-work/lucene-solr/solr$ ./bin/solr start -e techproducts
[master] ~/apache-work/lucene-solr/solr$ ./bin/solr stop
[master] ~/apache-work/lucene-solr/solr$ ./bin/solr start -e techproducts
Solr home directory
/Users/varun/apache-work/lucene-solr/solr/example/techproducts/solr already
exists.
Starting up Solr on port 8983 using command:
bin/solr start -p 8983 -s "example/techproducts/solr"
Archiving 1 old GC log files to
/Users/varun/apache-work/lucene-solr/solr/example/techproducts/solr/../logs/archived
Archiving 1 console log files to
/Users/varun/apache-work/lucene-solr/solr/example/techproducts/solr/../logs/archived
Rotating solr logs, keeping a max of 9 generations
Waiting up to 180 seconds to see Solr running on port 8983 [\]
Started Solr server on port 8983 (pid=53397). Happy searching!
Creating new core 'techproducts' using command:
http://localhost:8983/solr/admin/cores?action=CREATE=techproducts=techproducts
ERROR: Error CREATEing SolrCore 'techproducts': Could not create a new core in
/Users/varun/apache-work/lucene-solr/solr/example/techproducts/solr/techproductsas
another core is already defined there
ERROR: Failed to create techproducts using command: [-name, techproducts,
-shards, 1, -replicationFactor, 1, -confname, techproducts, -confdir,
sample_techproducts_configs, -configsetsDir,
/Users/varun/apache-work/lucene-solr/solr/server/solr/configsets, -solrUrl,
http://localhost:8983/solr]
{code}
was (Author: varunthacker):
I tried out the patch against master and I get this error
{code}
[master] ~/apache-work/lucene-solr/solr$ ./bin/solr start -e techproducts
Solr home directory
/Users/varun/apache-work/lucene-solr/solr/example/techproducts/solr already
exists.
Starting up Solr on port 8983 using command:
bin/solr start -p 8983 -s "example/techproducts/solr"
Archiving 1 old GC log files to
/Users/varun/apache-work/lucene-solr/solr/example/techproducts/solr/../logs/archived
Archiving 1 console log files to
/Users/varun/apache-work/lucene-solr/solr/example/techproducts/solr/../logs/archived
Rotating solr logs, keeping a max of 9 generations
Waiting up to 180 seconds to see Solr running on port 8983 [\]
Started Solr server on port 8983 (pid=53397). Happy searching!
Creating new core 'techproducts' using command:
http://localhost:8983/solr/admin/cores?action=CREATE=techproducts=techproducts
ERROR: Error CREATEing SolrCore 'techproducts': Could not create a new core in
/Users/varun/apache-work/lucene-solr/solr/example/techproducts/solr/techproductsas
another core is already defined there
ERROR: Failed to create techproducts using command: [-name, techproducts,
-shards, 1, -replicationFactor, 1, -confname, techproducts, -confdir,
sample_techproducts_configs, -configsetsDir,
/Users/varun/apache-work/lucene-solr/solr/server/solr/configsets, -solrUrl,
http://localhost:8983/solr]
{code}
> The schemaless example can not be started after being stopped.
> --
>
> Key: SOLR-9867
> URL: https://issues.apache.org/jira/browse/SOLR-9867
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mark Miller
> Fix For: master (7.0), 6.4
>
> Attachments: SOLR-9867.patch, SOLR-9867.patch
>
>
> I'm having trouble when I start up the schemaless example after shutting down.
> I first tracked this down to the fact that the run example tool is getting an
> error when it tries to create the SolrCore (again, it already exists) and so
> it deletes the cores instance dir which leads to tlog and index lock errors
> in Solr.
> The reason it seems to be trying to create the core when it already exists is
> that the run example tool uses a core status call to check existence and
> because the core is loading, we don't consider it as existing. I added a
> check to look for core.properties.
> That seemed to let me start up, but my first requests failed because the core
> was still loading. It appears CoreContainer#getCore is supposed to be
> blocking so you don't have this problem, but there must be an issue, because
> it is not blocking.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
[jira] [Comment Edited] (SOLR-9867) The schemaless example can not be started after being stopped.
[
https://issues.apache.org/jira/browse/SOLR-9867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15788522#comment-15788522
]
Mark Miller edited comment on SOLR-9867 at 12/30/16 11:07 PM:
--
Thanks for looking into this Varun.
I think this behavior was built into CoreContainer previously and must have
been removed in a refactoring. Now I see no code that actually waits for a core
to load, just the methods on CoreContainer for it.
So we can restore the expected behavior here and wait for the core to load
rather than throw an exception:
{noformat}
if (core != null) {
path = path.substring(idx);
} else if (cores.isCoreLoading(corename)) { // extra mem barriers, so
don't look at this before trying to get core
throw new SolrException(ErrorCode.SERVICE_UNAVAILABLE, "SolrCore is
loading");
} else {
// the core may have just finished loading
core = cores.getCore(corename);
if (core != null) {
path = path.substring(idx);
}
}
{noformat}
was (Author: markrmil...@gmail.com):
Thanks for looking into this Varun.
I think this behavior was built into CoreContainer previously and must have
been removed in a refactoring. Now I see no code that actually waits for a core
to load, just the methods on CoreContainer for it.
So we can restore the expected behavior here and wait for the core to load
rather than throw an exception:
{noformat}
if (core != null) {
path = path.substring(idx);
} else if (cores.isCoreLoading(corename)) { // extra mem barriers, so
don't look at this before trying to get core
throw new SolrException(ErrorCode.SERVICE_UNAVAILABLE, "SolrCore is
loading");
} else {
// the core may have just finished loading
core = cores.getCore(corename);
if (core != null) {
path = path.substring(idx);
}
}
{noformat}
I think it now causes a loading exception to be thrown rather than waiting for
the core to load though.
> The schemaless example can not be started after being stopped.
> --
>
> Key: SOLR-9867
> URL: https://issues.apache.org/jira/browse/SOLR-9867
> Project: Solr
> Issue Type: Bug
> Security Level: Public(Default Security Level. Issues are Public)
>Reporter: Mark Miller
> Fix For: master (7.0), 6.4
>
>
> I'm having trouble when I start up the schemaless example after shutting down.
> I first tracked this down to the fact that the run example tool is getting an
> error when it tries to create the SolrCore (again, it already exists) and so
> it deletes the cores instance dir which leads to tlog and index lock errors
> in Solr.
> The reason it seems to be trying to create the core when it already exists is
> that the run example tool uses a core status call to check existence and
> because the core is loading, we don't consider it as existing. I added a
> check to look for core.properties.
> That seemed to let me start up, but my first requests failed because the core
> was still loading. It appears CoreContainer#getCore is supposed to be
> blocking so you don't have this problem, but there must be an issue, because
> it is not blocking.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
-
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
