Re: problem with schema.xml
: 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
Re: problem with schema.xml
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, [EMAIL PROTECTED] 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 [EMAIL PROTECTED]: 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...
Re: problem with schema.xml
: 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
problem with schema.xml
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
Re: problem with schema.xml
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... [EMAIL PROTECTED] 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
Re: problem with schema.xml
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 [EMAIL PROTECTED]: 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...
