Re: Core reload vs servlet container restart
Hmmm, may be a bug, can you reliably reproduce this?
About the admin/schema that is simply a file transfer from
the schema file, it's not reconstructed from the current
internal representation in Solr. So the fact that your change
shows up there is unrelated to whether the Solr instance
knows about your changes. I think you could make the
changes and NOT reload the core and you'd still see it.
A bit confusing, true.
Best
Erick
On Thu, Nov 10, 2011 at 9:31 AM, Tanguy Moal tanguy.m...@gmail.com wrote:
Dear list,
I've experienced a weird (unexpected?) behaviour concerning core reload on a
master instance.
My setup :
master/slave on separate hosts.
On the master, I update the schema.xml file, adding a dynamic field of type
random sort field.
I reload the master using core admin.
The new field is *not* taken into account.
I restart the servlet container (jetty in my case).
The new field is taken into account, I can perform random sort operations.
On the slave side, no problem : at startup the schema.xml replicated, the
core reloaded, and I was able to perform random sorts as well.
Now the question is : what was wrong with the core reload on the master ?
The output it gave to me was something like : sort param field can't be
found : ${fieldName}.
At this point, in admin/schema view, the schema showing up was indeed
showing the freshly added dynamic field.
I had to restart jetty (not a big issue here, but just to be sure).
Thanks!
--
Tanguy
Re: Core reload vs servlet container restart
What version of Solr?
When you look at the logs, does a new SolrCore look like it comes up right away?
It sounds like perhaps the old SolrCore is still serving requests - how long do
you wait before trying to restart jetty?
Anything interesting in the logs around that time?
- Mark Miller
lucidimagination.com
On Nov 10, 2011, at 9:31 AM, Tanguy Moal wrote:
Dear list,
I've experienced a weird (unexpected?) behaviour concerning core reload on a
master instance.
My setup :
master/slave on separate hosts.
On the master, I update the schema.xml file, adding a dynamic field of type
random sort field.
I reload the master using core admin.
The new field is *not* taken into account.
I restart the servlet container (jetty in my case).
The new field is taken into account, I can perform random sort operations.
On the slave side, no problem : at startup the schema.xml replicated, the
core reloaded, and I was able to perform random sorts as well.
Now the question is : what was wrong with the core reload on the master ?
The output it gave to me was something like : sort param field can't be
found : ${fieldName}.
At this point, in admin/schema view, the schema showing up was indeed showing
the freshly added dynamic field.
I had to restart jetty (not a big issue here, but just to be sure).
Thanks!
--
Tanguy
Core reload vs servlet container restart
Dear list,
I've experienced a weird (unexpected?) behaviour concerning core reload
on a master instance.
My setup :
master/slave on separate hosts.
On the master, I update the schema.xml file, adding a dynamic field of
type random sort field.
I reload the master using core admin.
The new field is *not* taken into account.
I restart the servlet container (jetty in my case).
The new field is taken into account, I can perform random sort operations.
On the slave side, no problem : at startup the schema.xml replicated,
the core reloaded, and I was able to perform random sorts as well.
Now the question is : what was wrong with the core reload on the master ?
The output it gave to me was something like : sort param field can't be
found : ${fieldName}.
At this point, in admin/schema view, the schema showing up was indeed
showing the freshly added dynamic field.
I had to restart jetty (not a big issue here, but just to be sure).
Thanks!
--
Tanguy
