problem with schema.xml

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

problem with schema.xml

mirko-9
Hi,

I just started playing around with Solr 1.2.  It has some nice improvements.
I noticed that errors in the schema.xml get reported in a verbose way now, but
the following steps cause a problem for me:

1. start with a correct schema.xml - Solr works fine
2. edit it in a way that is no longer correct (say, remove the </schema> closing
tag - Solr works fine
3. restart the webapp (through the Tomcat manager interface) - Solr complains
that the schema.xml does not parse, fine.
4. now restart again (without fixing the schema.xml!) - Solr won't even start up
5. fix the above problem (add the closing tag) and restart via Tomcat's manager
- the webapp cannot restart showing that there is a problem:
FAIL - Application at context path /furness could not be started

The following steps might seem artificial, but assume you don't manage to fix
all the typos in your schema.xml for the first attempt.  It seems after restart
Solr gets stuck in some state and I cannot get it up and running by Tomcat's
manager, only by restarting Tomcat.

Am I missing something?
Thanks,
mirko
Reply | Threaded
Open this post in threaded view
|

Re: problem with schema.xml

Ryan McKinley
I don't use tomcat, so I can't be particularly useful.  The behavior you
describe does not happen with resin or jetty...

My guess is that tomcat is caching the error state.  Since fixing the
problem is outside the webapp directory, it does not think it has
changed so it stays in a broken state.

if you "touch" the .war file, does it restart ok?

but i'm just guessing...


[hidden email] wrote:

> Hi,
>
> I just started playing around with Solr 1.2.  It has some nice improvements.
> I noticed that errors in the schema.xml get reported in a verbose way now, but
> the following steps cause a problem for me:
>
> 1. start with a correct schema.xml - Solr works fine
> 2. edit it in a way that is no longer correct (say, remove the </schema> closing
> tag - Solr works fine
> 3. restart the webapp (through the Tomcat manager interface) - Solr complains
> that the schema.xml does not parse, fine.
> 4. now restart again (without fixing the schema.xml!) - Solr won't even start up
> 5. fix the above problem (add the closing tag) and restart via Tomcat's manager
> - the webapp cannot restart showing that there is a problem:
> FAIL - Application at context path /furness could not be started
>
> The following steps might seem artificial, but assume you don't manage to fix
> all the typos in your schema.xml for the first attempt.  It seems after restart
> Solr gets stuck in some state and I cannot get it up and running by Tomcat's
> manager, only by restarting Tomcat.
>
> Am I missing something?
> Thanks,
> mirko
>

Reply | Threaded
Open this post in threaded view
|

Re: problem with schema.xml

mirko-9
Hi Ryan,

I have my .war file located outside the webapps folder (I am using multiple
Solr instances with a config as suggested on the wiki:
http://wiki.apache.org/solr/SolrTomcat).

Nevertheless, I touched the .war file, the config file, the directory under
webapps, but nothing seems to be working.

Any other suggestions?  Is someone else experiencing the same problem?
thanks,
mirko


Quoting Ryan McKinley <[hidden email]>:

> I don't use tomcat, so I can't be particularly useful.  The behavior you
> describe does not happen with resin or jetty...
>
> My guess is that tomcat is caching the error state.  Since fixing the
> problem is outside the webapp directory, it does not think it has
> changed so it stays in a broken state.
>
> if you "touch" the .war file, does it restart ok?
>
> but i'm just guessing...
>
>
Reply | Threaded
Open this post in threaded view
|

Re: problem with schema.xml

Jonathan Traylor-2
I am having a similar(?) problem with 1.2 upgraded from an earlier
incubator release. We upgraded by building the new war with ant by and
replacing jetty's webapps/solr.war -- changes to schema.xml are not
taking place by the method of exchanging solr/conf/schema.xml for an
updated one with a new field name="foobar" and restarting the sending
the solr java process a TERM and starting afresh...

--
Jonathan

On Fri, Jun 08, 2007 at 03:17:30PM -0400, [hidden email] wrote:

> Hi Ryan,
>
> I have my .war file located outside the webapps folder (I am using multiple
> Solr instances with a config as suggested on the wiki:
> http://wiki.apache.org/solr/SolrTomcat).
>
> Nevertheless, I touched the .war file, the config file, the directory under
> webapps, but nothing seems to be working.
>
> Any other suggestions?  Is someone else experiencing the same problem?
> thanks,
> mirko
>
>
> Quoting Ryan McKinley <[hidden email]>:
>
> > I don't use tomcat, so I can't be particularly useful.  The behavior you
> > describe does not happen with resin or jetty...
> >
> > My guess is that tomcat is caching the error state.  Since fixing the
> > problem is outside the webapp directory, it does not think it has
> > changed so it stays in a broken state.
> >
> > if you "touch" the .war file, does it restart ok?
> >
> > but i'm just guessing...
> >
> >
Reply | Threaded
Open this post in threaded view
|

Re: problem with schema.xml

Chris Hostetter-3
: replacing jetty's webapps/solr.war -- changes to schema.xml are not
: taking place by the method of exchanging solr/conf/schema.xml for an
: updated one with a new field name="foobar" and restarting the sending
: the solr java process a TERM and starting afresh...

you're terminated the java process and starting a new one and it's not
seeing the new file?  That's, ... hmm, i really have no idea what that is.

Are you sure the first process is completely shutting down?  If the old
process is still listening on the port the new process won't start up
cleanly.  Other then that, i can't think of any reason why a new java
process wouldn't see the new file.


-Hoss

Reply | Threaded
Open this post in threaded view
|

Re: problem with schema.xml

Jonathan Traylor-2
The java process is terminating to the point of not being visible in
the process list. As with my other experiences when shutting down java
processes it takes approximiately 5 seconds to completely go away. At
least to the point of nothing listening on the port I am aware that
refreshes of the solr admin interface in a web browser fails. I also
get fresh log messages when the server is started again. The new
schema.xml that shows the changes is via:

http://localhost:8983/solr/admin/get-file.jsp?file=schema.xml

Maybe there's some extra magic to getting the new field to show up at
all as null or something valuable? Is that the behaviour of the
default field tag?

Or maybe there's something deeper...

--
Jonathan

On Mon, Jun 11, 2007 at 10:32:26PM -0700, Chris Hostetter wrote:

> : replacing jetty's webapps/solr.war -- changes to schema.xml are not
> : taking place by the method of exchanging solr/conf/schema.xml for an
> : updated one with a new field name="foobar" and restarting the sending
> : the solr java process a TERM and starting afresh...
>
> you're terminated the java process and starting a new one and it's not
> seeing the new file?  That's, ... hmm, i really have no idea what that is.
>
> Are you sure the first process is completely shutting down?  If the old
> process is still listening on the port the new process won't start up
> cleanly.  Other then that, i can't think of any reason why a new java
> process wouldn't see the new file.
>
>
> -Hoss
>
Reply | Threaded
Open this post in threaded view
|

Re: problem with schema.xml

Chris Hostetter-3

: get fresh log messages when the server is started again. The new
: schema.xml that shows the changes is via:
:
: http://localhost:8983/solr/admin/get-file.jsp?file=schema.xml
:
: Maybe there's some extra magic to getting the new field to show up at
: all as null or something valuable? Is that the behaviour of the
: default field tag?

whoa ... wait a minute: i think there is a disconect in what exactly
should happen when you change your schema.xml ... adding a new field
doesn't automaticly create a value ofr that field for every document --
a new stored field won't magicly appear as empty in every document
returned when you do a search, adding a new field just means that you can
now add documents with that field.

so it seems like your new schema.xml probably is being loaded fine when
you restart your server -- you can be certain if you try to index a
document with that new field and it works.



-Hoss