org.apache.jasper.JasperException: Exception in JSP: /admin/_info.jsp:27
Hi all, I'm trying to install Solr in a Tomcat 5.5.17 container on Linux Fedora core 5. I receive org.apache.jasper.JasperException: Exception in JSP: /admin/_info.jsp:27. Full error given below. I'm following the instructions on the WIKI I have copied the solr.war (from apache-solr-1.1.0) to $CATALINA_HOME/webapps. I have copied the example solr home example/solr as a template for my solr home. I then start tomcat from the same directory which contains this solr directory as instructed in the wiki. Any help would be much appreciated, Thanks Karen Full Error: type Exception report INFO: Deploying web application archive solr.war Apr 3, 2007 2:52:47 PM org.apache.solr.servlet.SolrServlet init INFO: SolrServlet.init() Apr 3, 2007 2:52:47 PM org.apache.solr.servlet.SolrServlet init INFO: No /solr/home in JNDI Apr 3, 2007 2:52:47 PM org.apache.solr.servlet.SolrServlet init message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: Exception in JSP: /admin/_info.jsp:27 24: 25: %-- jsp:include page=header.jsp/ --% 26: %-- do a verbatim include so we can use the local vars --% 27: [EMAIL PROTECTED] file=header.jsp % 28: 29: br clear=all 30: table Stacktrace: org.apache.jasper.servlet.JspServletWrapper.handleJspException(JspServletWrapper.java:504) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:375) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause javax.servlet.ServletException org.apache.jasper.runtime.PageContextImpl.doHandlePageException(PageContextImpl.java:858) org.apache.jasper.runtime.PageContextImpl.handlePageException(PageContextImpl.java:791) org.apache.jsp.admin.index_jsp._jspService(index_jsp.java:313) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause java.lang.NoClassDefFoundError org.apache.jsp.admin.index_jsp._jspService(index_jsp.java:80) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service(JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile(JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
Re: org.apache.jasper.JasperException: Exception in JSP: /admin/_info.jsp:27
Thanks Geoff, I installed a clean version of tomcat 5.5.23 and carried out the exact same steps as before ... and it worked !! It also works configuring solr home with JNDI (which also failed under my TC 5.5.17). Its possible I guess that some earlier changes/additions to my 5.5.17 conflicted with solr configuration. But I'm going to use Tc 5.5.23 from here on, Many thanks for your help, Karen On Tue, 2007-04-03 at 21:00 -0700, Jeff Rodenburg wrote: Whenever I've encountered this, the cause has nearly always been starting tomcat with the proper current working directory. I went through the example install a few weeks ago, line by line, from the wiki page for Tomcat and it ran fine. I'm running 5.5.17, and have done this on both FC5 and FC6. Other things of importance: proper chmod settings on /bin under apache-tomcat. Hope this helps. -- j On 4/3/07, Karen Loughran [EMAIL PROTECTED] wrote: Hi all, I'm trying to install Solr in a Tomcat 5.5.17 container on Linux Fedora core 5. I receive org.apache.jasper.JasperException: Exception in JSP: /admin/_info.jsp:27. Full error given below. I'm following the instructions on the WIKI I have copied the solr.war (from apache-solr-1.1.0) to $CATALINA_HOME/webapps. I have copied the example solr home example/solr as a template for my solr home. I then start tomcat from the same directory which contains this solr directory as instructed in the wiki. Any help would be much appreciated, Thanks Karen Full Error: type Exception report INFO: Deploying web application archive solr.war Apr 3, 2007 2:52:47 PM org.apache.solr.servlet.SolrServlet init INFO: SolrServlet.init() Apr 3, 2007 2:52:47 PM org.apache.solr.servlet.SolrServlet init INFO: No /solr/home in JNDI Apr 3, 2007 2:52:47 PM org.apache.solr.servlet.SolrServlet init message description The server encountered an internal error () that prevented it from fulfilling this request. exception org.apache.jasper.JasperException: Exception in JSP: /admin/_info.jsp:27 24: 25: %-- jsp:include page=header.jsp/ --% 26: %-- do a verbatim include so we can use the local vars --% 27: [EMAIL PROTECTED] file=header.jsp % 28: 29: br clear=all 30: table Stacktrace: org.apache.jasper.servlet.JspServletWrapper.handleJspException( JspServletWrapper.java:504) org.apache.jasper.servlet.JspServletWrapper.service( JspServletWrapper.java:375) org.apache.jasper.servlet.JspServlet.serviceJspFile( JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause javax.servlet.ServletException org.apache.jasper.runtime.PageContextImpl.doHandlePageException( PageContextImpl.java:858) org.apache.jasper.runtime.PageContextImpl.handlePageException( PageContextImpl.java:791) org.apache.jsp.admin.index_jsp._jspService(index_jsp.java:313) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service( JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile( JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) root cause java.lang.NoClassDefFoundError org.apache.jsp.admin.index_jsp._jspService(index_jsp.java:80) org.apache.jasper.runtime.HttpJspBase.service(HttpJspBase.java:97) javax.servlet.http.HttpServlet.service(HttpServlet.java:802) org.apache.jasper.servlet.JspServletWrapper.service( JspServletWrapper.java:332) org.apache.jasper.servlet.JspServlet.serviceJspFile( JspServlet.java:314) org.apache.jasper.servlet.JspServlet.service(JspServlet.java:264) javax.servlet.http.HttpServlet.service(HttpServlet.java:802)
solr-1.2.0 java.util.concurrent.RejectedExecutionException
Hi all, I have downloaded the latest Solr and have created a solr utility jar based on EmbeddedSolr from the wiki, (http://wiki.apache.org/solr/SolJava). My jar has a search method which basically gets the solr core and calls searchSolr (identical to that in EmbeddedSolr) with the passed in string and closes the core before exiting the method. When I make two subsequent calls to my search method from a client program I get the following exception on the 2nd attempt: 29-Jun-2007 13:51:50 org.apache.solr.search.SolrIndexSearcher init INFO: Opening [EMAIL PROTECTED] main 29-Jun-2007 13:51:50 org.apache.solr.core.SolrException log SEVERE: java.util.concurrent.RejectedExecutionException at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(ThreadPoolExecutor.java:1759) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:767) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:658) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorService.java:92) at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors.java:603) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:536) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:324) at org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequestBase.java:173) at org.apache.solr.request.StandardRequestHandler.handleRequestBody(StandardRequestHandler.java:114) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBase.java:77) at org.apache.solr.core.SolrCore.execute(SolrCore.java:658) at uk.ac.besc.prism.searcher.impl.SolrSearcher.searchSolr(Unknown Source) at uk.ac.besc.prism.searcher.impl.SolrSearcher.searchSolr(Unknown Source) at uk.ac.besc.prism.searcher.impl.SolrSearcher.searchStarts(Unknown Source) at uk.ac.besc.prism.searcher.client.TestSearchDirect.main(TestSearchDirect.java:47) By the way, EmbeddedSolr as provided works fine, no such exception. I also tried putting a sleep for 5 seconds in case the core had not properly closed before I tried opening it again (through the 2nd call to search). I noticed a discussion in February about the RejectedExecutionException, but its not clear to me whether there was a resolution to it ? http://www.mail-archive.com/[EMAIL PROTECTED]/msg02822.html Can anyone tell me what is causing this and how I can work around it ? Many thanks Karen Loughran
Re: solr-1.2.0 java.util.concurrent.RejectedExecutionException
Yonik, Thanks for your reply, I originally had implemented it as you suggest, ie, opened the core in a static initialiser and never closed it, but my client hangs - AFTER receiving the response back from solr (and after response from my utility jar). I have now changed back to this approach, but... I have to put a System.exit(0) at the end of my client code so that it can terminate. Seems like there may be a thread still hanging around preventing my client from exiting. Could this be to do with the ExecutorService using the default thread factory which will create non-daemon threads ? My utility jar is a standalone java library (not a webservice). Many thanks, Karen On Friday 29 June 2007 15:00:49 Yonik Seeley wrote: On 6/29/07, Karen Loughran [EMAIL PROTECTED] wrote: Hi all, I have downloaded the latest Solr and have created a solr utility jar based on EmbeddedSolr from the wiki, (http://wiki.apache.org/solr/SolJava). My jar has a search method which basically gets the solr core and calls searchSolr (identical to that in EmbeddedSolr) with the passed in string and closes the core before exiting the method. When I make two subsequent calls to my search method from a client program I get the following exception on the 2nd attempt: Yes, because the SolrCore (currently a static singleton) has been closed. In your search method, don't call close() on the core... it should hang around for the lifetime of your application. -Yonik 29-Jun-2007 13:51:50 org.apache.solr.search.SolrIndexSearcher init INFO: Opening [EMAIL PROTECTED] main 29-Jun-2007 13:51:50 org.apache.solr.core.SolrException log SEVERE: java.util.concurrent.RejectedExecutionException at java.util.concurrent.ThreadPoolExecutor$AbortPolicy.rejectedExecution(Thr eadPoolExecutor.java:1759) at java.util.concurrent.ThreadPoolExecutor.reject(ThreadPoolExecutor.java:76 7) at java.util.concurrent.ThreadPoolExecutor.execute(ThreadPoolExecutor.java:6 58) at java.util.concurrent.AbstractExecutorService.submit(AbstractExecutorServi ce.java:92) at java.util.concurrent.Executors$DelegatedExecutorService.submit(Executors. java:603) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:536) at org.apache.solr.core.SolrCore.getSearcher(SolrCore.java:324) at org.apache.solr.request.SolrQueryRequestBase.getSearcher(SolrQueryRequest Base.java:173) at org.apache.solr.request.StandardRequestHandler.handleRequestBody(Standard RequestHandler.java:114) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBa se.java:77) at org.apache.solr.core.SolrCore.execute(SolrCore.java:658) at uk.ac.besc.prism.searcher.impl.SolrSearcher.searchSolr(Unknown Source) at uk.ac.besc.prism.searcher.impl.SolrSearcher.searchSolr(Unknown Source) at uk.ac.besc.prism.searcher.impl.SolrSearcher.searchStarts(Unknown Source) at uk.ac.besc.prism.searcher.client.TestSearchDirect.main(TestSearchDirect.j ava:47) By the way, EmbeddedSolr as provided works fine, no such exception. I also tried putting a sleep for 5 seconds in case the core had not properly closed before I tried opening it again (through the 2nd call to search). I noticed a discussion in February about the RejectedExecutionException, but its not clear to me whether there was a resolution to it ? http://www.mail-archive.com/[EMAIL PROTECTED]/msg02822.html Can anyone tell me what is causing this and how I can work around it ? Many thanks Karen Loughran
java.lang.ExceptionInInitializerError - Can't find resource 'solrconfig.xml'
Hi there, I have a standalone java/solr embedded application (based on Embedded Solr). I can call it from the command prompt by passing solr.home as system property ( -Dsolr.solr.home=/opt/all/solr ) and all works fine. But if I put a webservice infront of it ,which essentially provides an webapp api to the standalone (deployed in tomcat 5.5.23) and set up solr.home via JNDI I get the exception below. The trace indicates that it is correctly using JNDI solr.home /opt/all/solr which does have conf directory with solrconfig.xml, etc. It is the same solr.home which works for testing standalone. But the stack trace below reports that it can't find solrconfig.xml at this location. Any ideas as to what is happening ? Many Thanks Karen PS. Using Solr 1.2 04-Jul-2007 11:16:39 org.apache.solr.core.Config getInstanceDir INFO: Using JNDI solr.home: /opt/all/solr 04-Jul-2007 11:16:39 org.apache.solr.core.Config setInstanceDir INFO: Solr home set to '/opt/all/solr/' java.lang.ExceptionInInitializerError at org.apache.solr.update.SolrIndexConfig.clinit(SolrIndexConfig.java:36) at org.apache.solr.core.SolrCore.clinit(SolrCore.java:84) at uk.ac.besc.prism.searcher.impl.searcher.clinit(Unknown Source) at java.lang.Class.forName0(Native Method) at java.lang.Class.forName(Class.java:247) at org.apache.axis.utils.ClassUtils$1.run(ClassUtils.java:127) at java.security.AccessController.doPrivileged(Native Method) at org.apache.axis.utils.ClassUtils.forName(ClassUtils.java:122) at org.apache.axis.utils.cache.ClassCache.lookup(ClassCache.java:85) at org.apache.axis.providers.java.JavaProvider.getServiceClass(JavaProvider.java:428) at org.apache.axis.providers.java.JavaProvider.initServiceDesc(JavaProvider.java:461) at org.apache.axis.handlers.soap.SOAPService.getInitializedServiceDesc(SOAPService.java:286) at org.apache.axis.deployment.wsdd.WSDDService.makeNewInstance(WSDDService.java:500) at org.apache.axis.deployment.wsdd.WSDDDeployableItem.getNewInstance(WSDDDeployableItem.java:274) at org.apache.axis.deployment.wsdd.WSDDDeployableItem.getInstance(WSDDDeployableItem.java:260) at org.apache.axis.deployment.wsdd.WSDDDeployment.getService(WSDDDeployment.java:427) at org.apache.axis.configuration.FileProvider.getService(FileProvider.java:231) at org.apache.axis.AxisEngine.getService(AxisEngine.java:311) at org.apache.axis.MessageContext.setTargetService(MessageContext.java:756) at org.apache.axis.handlers.http.URLMapper.invoke(URLMapper.java:50) at org.apache.axis.handlers.http.URLMapper.generateWSDL(URLMapper.java:58) at org.apache.axis.strategies.WSDLGenStrategy.visit(WSDLGenStrategy.java:33) at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) at org.apache.axis.SimpleChain.generateWSDL(SimpleChain.java:104) at org.apache.axis.server.AxisServer.generateWSDL(AxisServer.java:446) at org.apache.axis.transport.http.QSWSDLHandler.invoke(QSWSDLHandler.java:68) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.axis.transport.http.AxisServlet.processQuery(AxisServlet.java:1226) at org.apache.axis.transport.http.AxisServlet.doGet(AxisServlet.java:249) at javax.servlet.http.HttpServlet.service(HttpServlet.java:690) at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at
Re: java.lang.ExceptionInInitializerError - Can't find resource 'solrconfig.xml'
Chris, When I remove the surrounding quotes from solr path in my web.xml it works ! Thanks for your help Karen On Wednesday 04 July 2007 16:56:40 Chris Hostetter wrote: : But if I put a webservice infront of it ,which essentially provides an : webapp api to the standalone (deployed in tomcat 5.5.23) and set up : solr.home via JNDI I get the exception below. The trace indicates that : it is correctly using JNDI solr.home /opt/all/solr which does have conf : directory with note the quote characters in the logging and read further down in the stack trace... : 04-Jul-2007 11:16:39 org.apache.solr.core.Config getInstanceDir : INFO: Using JNDI solr.home: /opt/all/solr : 04-Jul-2007 11:16:39 org.apache.solr.core.Config setInstanceDir : INFO: Solr home set to '/opt/all/solr/' ... : Caused by: java.lang.RuntimeException: Error in solrconfig.xml : at org.apache.solr.core.SolrConfig.clinit(SolrConfig.java:90) : ... 49 more : Caused by: java.lang.RuntimeException: Can't find resource : 'solrconfig.xml' in classpath or '/opt/all/solr/conf/', : cwd=/opt/all/apache-tomcat-5.5.23 ...it looks like when you set solr home using JNDI, the mechanism you are using is actaully putting the quote characters in the value, so it's trying to find a file with the path... /opt/all/solr/conf/ -Hoss
Re: Solr Server Configuration
I use solr with tomcat 5.5.23. I have successfully used Darren Erik Vengroff's java client for adding and deleting found on this page. http://wiki.apache.org/solr/SolJava I also successfully use EmbeddedSolr for direct API usage (found at the end of this link) Karen On Friday 06 July 2007 06:26:52 nithyavembu wrote: Hi All, I am new to Solr. But i am familiar with lucene. I am stuggling in solr server configuation.I am using Tomcat 5. I have worked with the example standalone given with solr while i download. But my doubt is i) In lucene we add document by using java. But here they given in xml format and posting them using POST.jar. How can i add document in java? ii) How can i send the http request n get response in a standalone java program? iii) Whether i have to add any xml or i have to modify the xml (server.xml,web.xml) files for solr server configuration? Best, Nithya.V.
most popular/most commonly accessed records
Hi all, Is there a way through solr to find out about most commonly accessed solr documents ? So for example, my client may wish to list the top 10 most popular videos, based on previous accesses to them in the solr server db. If there are any solr features to help with this can someone point me to them ? Had a browse through the user documentation, but can't see anything obvious ? Many thanks Karen Loughran
wildcard searches standard request handler
Hi all, I understand from browsing through the mailing list that I won't be able to perform wildcard searches using disMax request handler. But why doesn't any of the following wildcard searches work when using the standard request handler: Firstly the following query accurately returns 27 documents: PublishedStart:Whenever Attempted Wildcard searches:-- Whene* URL: http://localhost:8080/solr/select/?q=Whene*version=2.2start=0rows=10indent=on PublishedStart:When* URL: http://localhost:8080/solr/select/?q=PublishedStart%3AWhen*version=2.2start=0rows=10indent=on PublishedStart:When* URL: http://localhost:8080/solr/select/?q=PublishedStart%3A%22When*%22version=2.2start=0rows=10indent=on -- PublishedStart is declared as : field name=PublishedStart type=text indexed=true stored=true / text is as defined in the default supplied schema.xml. I am using tomcat 5.5.23 with solr 1.2 Many thanks Karen
Result from server is not rooted with a result tag
Hi all, I'm using the code from solr-client which (downloaded from http://issues.apache.org/jira/browse/SOLR-20) to add new solr records programmatically with java to my db (solr 1.2). Basically: SolrClient client = new SolrClientImpl( new URL(http://localhost:8080/solr/) ); // Adding a document SimpleSolrDoc ex = new SimpleSolrDoc(); ex.setField( programId, programId ); ex.setField( Title, title); (and so on for each field) client.add( ex ); client.commit( true, true ); It used to work, but now I get the exception shown below: TCP mon shows the response back from the solr server as: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/xml;charset=UTF-8 Content-Length: 147 Date: Fri, 20 Jul 2007 09:31:21 GMT ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime3/int /lst /response Not sure what has changed ? Does anyone recognise this error ? Should this client code work with solr 1.2 ? many thanks Karen INFO: added id={bbc.co.uk/newsround/277108109} in 29ms 20-Jul-2007 11:28:31 org.apache.solr.core.SolrCore execute INFO: /update/ 0 44 org.apache.solr.client.exception.SolrClientException: Result from server is not rooted with a result tag. at org.apache.solr.client.impl.SolrClientImpl.postUpdateXml(SolrClientImpl.java:172) at org.apache.solr.client.impl.SolrClientImpl.add(SolrClientImpl.java:291) at org.apache.solr.client.impl.SolrClientImpl.add(SolrClientImpl.java:216) at uk.ac.besc.prism.publication.impl.publication.addSolrRecord(Unknown Source) at uk.ac.besc.prism.publication.impl.publication.notifyIndex(Unknown Source) at uk.ac.besc.prism.publication.impl.publication.publish(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:397) at org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java:186) at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323) at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java:32) at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:454) at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281) at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java:327) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.java:685) at java.lang.Thread.run(Thread.java:619) 2007-07-20 11:28:31,417 DEBUG impl.GroupMapper [debug:138] [EMAIL PROTECTED]
Re: Result from server is not rooted with a result tag
Thanks Otis, this works :-) Karen On Friday 20 July 2007 14:03:22 Otis Gospodnetic wrote: Hello Karen, You should grab solrj from its new home: http://solrstuff.org/svn/solrj/ Otis -- Lucene Consulting -- http://lucene-consulting.com/ - Original Message From: Karen Loughran [EMAIL PROTECTED] To: solr-user@lucene.apache.org Sent: Friday, July 20, 2007 12:41:28 PM Subject: Result from server is not rooted with a result tag Hi all, I'm using the code from solr-client which (downloaded from http://issues.apache.org/jira/browse/SOLR-20) to add new solr records programmatically with java to my db (solr 1.2). Basically: SolrClient client = new SolrClientImpl( new URL(http://localhost:8080/solr/) ); // Adding a document SimpleSolrDoc ex = new SimpleSolrDoc(); ex.setField( programId, programId ); ex.setField( Title, title); (and so on for each field) client.add( ex ); client.commit( true, true ); It used to work, but now I get the exception shown below: TCP mon shows the response back from the solr server as: HTTP/1.1 200 OK Server: Apache-Coyote/1.1 Content-Type: text/xml;charset=UTF-8 Content-Length: 147 Date: Fri, 20 Jul 2007 09:31:21 GMT ?xml version=1.0 encoding=UTF-8? response lst name=responseHeader int name=status0/int int name=QTime3/int /lst /response Not sure what has changed ? Does anyone recognise this error ? Should this client code work with solr 1.2 ? many thanks Karen INFO: added id={bbc.co.uk/newsround/277108109} in 29ms 20-Jul-2007 11:28:31 org.apache.solr.core.SolrCore execute INFO: /update/ 0 44 org.apache.solr.client.exception.SolrClientException: Result from server is not rooted with a result tag. at org.apache.solr.client.impl.SolrClientImpl.postUpdateXml(SolrClientImpl.jav a:172) at org.apache.solr.client.impl.SolrClientImpl.add(SolrClientImpl.java:291) at org.apache.solr.client.impl.SolrClientImpl.add(SolrClientImpl.java:216) at uk.ac.besc.prism.publication.impl.publication.addSolrRecord(Unknown Source) at uk.ac.besc.prism.publication.impl.publication.notifyIndex(Unknown Source) at uk.ac.besc.prism.publication.impl.publication.publish(Unknown Source) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:3 9) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImp l.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.axis.providers.java.RPCProvider.invokeMethod(RPCProvider.java:39 7) at org.apache.axis.providers.java.RPCProvider.processMessage(RPCProvider.java: 186) at org.apache.axis.providers.java.JavaProvider.invoke(JavaProvider.java:323) at org.apache.axis.strategies.InvocationStrategy.visit(InvocationStrategy.java :32) at org.apache.axis.SimpleChain.doVisiting(SimpleChain.java:118) at org.apache.axis.SimpleChain.invoke(SimpleChain.java:83) at org.apache.axis.handlers.soap.SOAPService.invoke(SOAPService.java:454) at org.apache.axis.server.AxisServer.invoke(AxisServer.java:281) at org.apache.axis.transport.http.AxisServlet.doPost(AxisServlet.java:699) at javax.servlet.http.HttpServlet.service(HttpServlet.java:710) at org.apache.axis.transport.http.AxisServletBase.service(AxisServletBase.java :327) at javax.servlet.http.HttpServlet.service(HttpServlet.java:803) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicatio nFilterChain.java:269) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterC hain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.j ava:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.j ava:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:12 7) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:11 7) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.jav a:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:151) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.process Connection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.ja va:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowerW orkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool.ja va:685) at java.lang.Thread.run(Thread.java:619) 2007-07-20 11:28:31,417 DEBUG impl.GroupMapper [debug:138] [EMAIL PROTECTED]
Re: SolrServerException: TEXT must be immediately followed by END_TAG and not START_TAG (position: START_TAG .....
Hi Ryan, Yes, I was using 1.2, But I've just downloaded the latest nightly build and it works ! Thanks Karen On Friday 20 July 2007 17:39:56 Ryan McKinley wrote: what version of solr are you running? 1.2? Solrj is only tested with the latest trunk build, but I *think* it should work on 1.2. Karen Loughran wrote: Hi all, Otis, I am now using the lastest solrj, and am trying to delete a solr record with both deleteById and deleteByQuery as follows: ... CommonsHttpSolrServer solr = new CommonsHttpSolrServer( new URL(http://localhost:8080/solr/;) ); SimpleSolrDoc ex = new SimpleSolrDoc(); String programId = kltest; // solr.deleteById( programId ); solr.deleteByQuery( programId:\kltest\ ); solr.commit(true, true); (programId is identified in the schema as unique identifier, also record with kltest definitely exists ). But at runtime I get the following exception ? I am using java version 1.6.0 and tomcat 5.5.23, Does anyone recognise this ? I am able to add records OK. Many Thanks Karen java org/apache/solr/client/example/SimpleExampleKLDelete EXECUTE:http://localhost:8080/solr/update org.apache.solr.client.solrj.SolrServerException: TEXT must be immediately followed by END_TAG and not START_TAG (position: START_TAG seen ...queryprogramId:kltestquery... @1:40) org.xmlpull.v1.XmlPullParserException: TEXT must be immediately followed by END_TAG and not START_TAG (position: START_TAG seen ...queryprogramId:kltestquery... @1:40) at org.xmlpull.mxp1.MXParser.nextText(MXParser.java:1063) at org.apache.solr.handler.XmlUpdateRequestHandler.update(XmlUpdateRequestHa ndler.java:251) at org.apache.solr.handler.XmlUpdateRequestHandler.handleRequestBody(XmlUpda teRequestHandler.java:84) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBa se.java:77) at org.apache.solr.core.SolrCore.execute(SolrCore.java:658) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.jav a:191) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.ja va:159) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicat ionFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilte rChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve .java:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve .java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java: 127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java: 117) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.j ava:108) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:15 1) at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:870 ) at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.proce ssConnection(Http11BaseProtocol.java:665) at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint. java:528) at org.apache.tomcat.util.net.LeaderFollowerWorkerThread.runIt(LeaderFollowe rWorkerThread.java:81) at org.apache.tomcat.util.threads.ThreadPool$ControlRunnable.run(ThreadPool. java:685) at java.lang.Thread.run(Thread.java:619) Caused by: Server side exception, status = 500: TEXT must be immediately followed by END_TAG and not START_TAG (position: START_TAG seen ...queryprogramId:kltestquery... @1:40) org.xmlpull.v1.XmlPullParserException: TEXT must be immediately followed by END_TAG and not START_TAG (position: START_TAG seen ...queryprogramId:kltestquery... @1:40)at org.xmlpull.mxp1.MXParser.nextText(MXParser.java:1063) at org.apache.solr.handler.XmlUpdateRequestHandler.update(XmlUpdateRequestHa ndler.java:251) at org.apache.solr.handler.XmlUpdateRequestHandler.handleRequestBody(XmlUpda teRequestHandler.java:84) at org.apache.solr.handler.RequestHandlerBase.handleRequest(RequestHandlerBa se.java:77) at org.apache.solr.core.SolrCore.execute(SolrCore.java:658) at org.apache.solr.servlet.SolrDispatchFilter.execute(SolrDispatchFilter.jav a:191) at org.apache.solr.servlet.SolrDispatchFilter.doFilter(SolrDispatchFilter.ja va:159) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicat ionFilterChain.java:215) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilte rChain.java:188) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve .java:210) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve .java:174) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java: 127) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java: 117
Is it possibily to dynamically/programmatically add new fields
Hi there, Is there a way in Solr to programmatically add new fields (named and dynamic) so that they don't have to be defined statically within schema.xml ? thanks Karen
CollectionDistribution - Changes reflected immediately on master, but only after tomcat restart on slave
Hiya, I have set up solr CollectionDistribution between a master and a slave with postCommit triggering snapshooter, and a cron job (snappuller and snapinstaller) on the slave accepting and installing updated snapshops every 15 minutes. Once I delete a record from the master (with java code using CommonsHttpSolrServer from solrj-1.3-dev) the change to the collection shows immediately - via both the http solr/admin query url and via a java client using CommonsHttpSolrServer from solrj-1.3-dev). But after distribution of this latest snapshop to the slave the collection does not show the update (with solr admin query url or via java query client) UNLESS I restart tomcat ? Can anyone explain to me why and perhaps what I need to do to get the change to reflect without a tomcat restart ? Many thanks Karen
Re: CollectionDistribution - Changes reflected immediately on master, but only after tomcat restart on slave
Thanks Yonik and Otis, I noticed from the log (snapinstaller.log) the following when the slave attempts to perform snapinstaller: 2007/10/29 10:30:02 started by 1001 2007/10/29 10:30:02 command: /opt/solr/bin/snapinstaller 2007/10/29 10:30:02 installing snapshot /opt/solr/data/snapshot.20071029102014 2007/10/29 10:30:02 notifing Solr to open a new Searcher 2007/10/29 10:30:02 failed to connect to Solr server 2007/10/29 10:30:02 snapshot installed but Solr server has not open a new Searcher 2007/10/29 10:30:02 failed (elapsed time: 0 sec) Running bin/commit -V works - the deleted record is then reflected in a search (without restarting tomcat). I then (testing delete of a different record) performed the snappuller and snappinstaller by hand on the slave and it worked, ie, no error in the log file and change reflected immediately ! So it seems that my cron job command is not working as expected: 0,15,30,45 * * * * /opt/solr/bin/snappuller /opt/solr/bin/snapinstaller ; separation for multuple commands (as per example given in solr document CollectionDistribution) did not work for me so I used according to crontab documentation. I also tried the following crontab job: 0,15,30,45 * * * * /opt/solr/bin/snappuller 1,16,31,46 * * * * /opt/solr/bin/snapinstaller Whereby snapinstaller would run a minute after snappuller. But I still get the following: 2007/10/29 11:16:01 started by 1001 2007/10/29 11:16:01 command: /opt/solr/bin/snapinstaller 2007/10/29 11:16:01 installing snapshot /opt/solr/data/snapshot.20071029111236 2007/10/29 11:16:01 notifing Solr to open a new Searcher 2007/10/29 11:16:01 failed to connect to Solr server 2007/10/29 11:16:01 snapshot installed but Solr server has not open a new Searcher 2007/10/29 11:16:01 failed (elapsed time: 0 sec) I have also confirmed with a whoami in crontab that the cron job is running as the same user as if running scripts by hand and as the user specified in scripts.conf. Do you know whey snapinstaller will not work within crontab but will work by hand ? Thanks Karen On Friday 26 October 2007 16:36:22 Yonik Seeley wrote: On 10/26/07, Karen Loughran [EMAIL PROTECTED] wrote: But after distribution of this latest snapshop to the slave the collection does not show the update (with solr admin query url or via java query client) UNLESS I restart tomcat ? Sounds like a config issue with the scripts... pulling the snapshot is obviously working, but snapinstaller (calling commit) is broken. try running bin/commit -V by hand on the slave -Yonik
Re: CollectionDistribution - Changes reflected immediately on master, but only after tomcat restart on slave
Hi Bill, yes, the commit.log shows the following when snapinstaller fails from the cronjob: 2007/10/29 15:03:03 started by 1001 2007/10/29 15:03:03 command: /opt/solr/bin/commit 2007/10/29 15:03:03 failed to connect to Solr server at http://localhost:8080/solr/update 2007/10/29 15:03:03 commit failed 2007/10/29 15:03:03 failed (elapsed time: 0 sec) solr is running on port 8080 on the localhost. When I subsequently run commit -V the log shows: 2007/10/29 15:06:35 started by autodeploy 2007/10/29 15:06:35 command: /opt/solr/bin/commit -V 2007/10/29 15:06:35 ended (elapsed time: 0 sec) Karen On Monday 29 October 2007 14:52:42 Bill Au wrote: Snapinstaller uses commit to notify Solr to open a new Searcher. Is there anything in the commit log which shows why the commit failed? Bill On 10/29/07, Karen Loughran [EMAIL PROTECTED] wrote: Thanks Yonik and Otis, I noticed from the log (snapinstaller.log) the following when the slave attempts to perform snapinstaller: 2007/10/29 10:30:02 started by 1001 2007/10/29 10:30:02 command: /opt/solr/bin/snapinstaller 2007/10/29 10:30:02 installing snapshot /opt/solr/data/snapshot.20071029102014 2007/10/29 10:30:02 notifing Solr to open a new Searcher 2007/10/29 10:30:02 failed to connect to Solr server 2007/10/29 10:30:02 snapshot installed but Solr server has not open a new Searcher 2007/10/29 10:30:02 failed (elapsed time: 0 sec) Running bin/commit -V works - the deleted record is then reflected in a search (without restarting tomcat). I then (testing delete of a different record) performed the snappuller and snappinstaller by hand on the slave and it worked, ie, no error in the log file and change reflected immediately ! So it seems that my cron job command is not working as expected: 0,15,30,45 * * * * /opt/solr/bin/snappuller /opt/solr/bin/snapinstaller ; separation for multuple commands (as per example given in solr document CollectionDistribution) did not work for me so I used according to crontab documentation. I also tried the following crontab job: 0,15,30,45 * * * * /opt/solr/bin/snappuller 1,16,31,46 * * * * /opt/solr/bin/snapinstaller Whereby snapinstaller would run a minute after snappuller. But I still get the following: 2007/10/29 11:16:01 started by 1001 2007/10/29 11:16:01 command: /opt/solr/bin/snapinstaller 2007/10/29 11:16:01 installing snapshot /opt/solr/data/snapshot.20071029111236 2007/10/29 11:16:01 notifing Solr to open a new Searcher 2007/10/29 11:16:01 failed to connect to Solr server 2007/10/29 11:16:01 snapshot installed but Solr server has not open a new Searcher 2007/10/29 11:16:01 failed (elapsed time: 0 sec) I have also confirmed with a whoami in crontab that the cron job is running as the same user as if running scripts by hand and as the user specified in scripts.conf. Do you know whey snapinstaller will not work within crontab but will work by hand ? Thanks Karen On Friday 26 October 2007 16:36:22 Yonik Seeley wrote: On 10/26/07, Karen Loughran [EMAIL PROTECTED] wrote: But after distribution of this latest snapshop to the slave the collection does not show the update (with solr admin query url or via java query client) UNLESS I restart tomcat ? Sounds like a config issue with the scripts... pulling the snapshot is obviously working, but snapinstaller (calling commit) is broken. try running bin/commit -V by hand on the slave -Yonik
Re: CollectionDistribution - Changes reflected immediately on master, but only after tomcat restart on slave
Hi Bill, just noticing that in the first instance it states started by 1001 and in the 2nd it reports started by autodeploy. The user id of autodeploy is in fact 1001. ? Karen On Monday 29 October 2007 15:07:55 Karen Loughran wrote: Hi Bill, yes, the commit.log shows the following when snapinstaller fails from the cronjob: 2007/10/29 15:03:03 started by 1001 2007/10/29 15:03:03 command: /opt/solr/bin/commit 2007/10/29 15:03:03 failed to connect to Solr server at http://localhost:8080/solr/update 2007/10/29 15:03:03 commit failed 2007/10/29 15:03:03 failed (elapsed time: 0 sec) solr is running on port 8080 on the localhost. When I subsequently run commit -V the log shows: 2007/10/29 15:06:35 started by autodeploy 2007/10/29 15:06:35 command: /opt/solr/bin/commit -V 2007/10/29 15:06:35 ended (elapsed time: 0 sec) Karen On Monday 29 October 2007 14:52:42 Bill Au wrote: Snapinstaller uses commit to notify Solr to open a new Searcher. Is there anything in the commit log which shows why the commit failed? Bill On 10/29/07, Karen Loughran [EMAIL PROTECTED] wrote: Thanks Yonik and Otis, I noticed from the log (snapinstaller.log) the following when the slave attempts to perform snapinstaller: 2007/10/29 10:30:02 started by 1001 2007/10/29 10:30:02 command: /opt/solr/bin/snapinstaller 2007/10/29 10:30:02 installing snapshot /opt/solr/data/snapshot.20071029102014 2007/10/29 10:30:02 notifing Solr to open a new Searcher 2007/10/29 10:30:02 failed to connect to Solr server 2007/10/29 10:30:02 snapshot installed but Solr server has not open a new Searcher 2007/10/29 10:30:02 failed (elapsed time: 0 sec) Running bin/commit -V works - the deleted record is then reflected in a search (without restarting tomcat). I then (testing delete of a different record) performed the snappuller and snappinstaller by hand on the slave and it worked, ie, no error in the log file and change reflected immediately ! So it seems that my cron job command is not working as expected: 0,15,30,45 * * * * /opt/solr/bin/snappuller /opt/solr/bin/snapinstaller ; separation for multuple commands (as per example given in solr document CollectionDistribution) did not work for me so I used according to crontab documentation. I also tried the following crontab job: 0,15,30,45 * * * * /opt/solr/bin/snappuller 1,16,31,46 * * * * /opt/solr/bin/snapinstaller Whereby snapinstaller would run a minute after snappuller. But I still get the following: 2007/10/29 11:16:01 started by 1001 2007/10/29 11:16:01 command: /opt/solr/bin/snapinstaller 2007/10/29 11:16:01 installing snapshot /opt/solr/data/snapshot.20071029111236 2007/10/29 11:16:01 notifing Solr to open a new Searcher 2007/10/29 11:16:01 failed to connect to Solr server 2007/10/29 11:16:01 snapshot installed but Solr server has not open a new Searcher 2007/10/29 11:16:01 failed (elapsed time: 0 sec) I have also confirmed with a whoami in crontab that the cron job is running as the same user as if running scripts by hand and as the user specified in scripts.conf. Do you know whey snapinstaller will not work within crontab but will work by hand ? Thanks Karen On Friday 26 October 2007 16:36:22 Yonik Seeley wrote: On 10/26/07, Karen Loughran [EMAIL PROTECTED] wrote: But after distribution of this latest snapshop to the slave the collection does not show the update (with solr admin query url or via java query client) UNLESS I restart tomcat ? Sounds like a config issue with the scripts... pulling the snapshot is obviously working, but snapinstaller (calling commit) is broken. try running bin/commit -V by hand on the slave -Yonik
Re: CollectionDistribution - Changes reflected immediately on master, but only after tomcat restart on slave
Hiya, I would just like to report that the problem with snapinstaller turned out to be that the default crontab environment PATH did not include path to where curl is installed (/usr/local/bin). so line 111 of commit script was failing : rs=`curl ${curl_url} -s -H 'Content-type:text/xml; charset=utf-8' -d commit/` I have now added an extra PATH setup in my crontab and it works :) Thanks, Karen On Monday 29 October 2007 15:41:55 Karen Loughran wrote: Hi Bill, just noticing that in the first instance it states started by 1001 and in the 2nd it reports started by autodeploy. The user id of autodeploy is in fact 1001. ? Karen On Monday 29 October 2007 15:07:55 Karen Loughran wrote: Hi Bill, yes, the commit.log shows the following when snapinstaller fails from the cronjob: 2007/10/29 15:03:03 started by 1001 2007/10/29 15:03:03 command: /opt/solr/bin/commit 2007/10/29 15:03:03 failed to connect to Solr server at http://localhost:8080/solr/update 2007/10/29 15:03:03 commit failed 2007/10/29 15:03:03 failed (elapsed time: 0 sec) solr is running on port 8080 on the localhost. When I subsequently run commit -V the log shows: 2007/10/29 15:06:35 started by autodeploy 2007/10/29 15:06:35 command: /opt/solr/bin/commit -V 2007/10/29 15:06:35 ended (elapsed time: 0 sec) Karen On Monday 29 October 2007 14:52:42 Bill Au wrote: Snapinstaller uses commit to notify Solr to open a new Searcher. Is there anything in the commit log which shows why the commit failed? Bill On 10/29/07, Karen Loughran [EMAIL PROTECTED] wrote: Thanks Yonik and Otis, I noticed from the log (snapinstaller.log) the following when the slave attempts to perform snapinstaller: 2007/10/29 10:30:02 started by 1001 2007/10/29 10:30:02 command: /opt/solr/bin/snapinstaller 2007/10/29 10:30:02 installing snapshot /opt/solr/data/snapshot.20071029102014 2007/10/29 10:30:02 notifing Solr to open a new Searcher 2007/10/29 10:30:02 failed to connect to Solr server 2007/10/29 10:30:02 snapshot installed but Solr server has not open a new Searcher 2007/10/29 10:30:02 failed (elapsed time: 0 sec) Running bin/commit -V works - the deleted record is then reflected in a search (without restarting tomcat). I then (testing delete of a different record) performed the snappuller and snappinstaller by hand on the slave and it worked, ie, no error in the log file and change reflected immediately ! So it seems that my cron job command is not working as expected: 0,15,30,45 * * * * /opt/solr/bin/snappuller /opt/solr/bin/snapinstaller ; separation for multuple commands (as per example given in solr document CollectionDistribution) did not work for me so I used according to crontab documentation. I also tried the following crontab job: 0,15,30,45 * * * * /opt/solr/bin/snappuller 1,16,31,46 * * * * /opt/solr/bin/snapinstaller Whereby snapinstaller would run a minute after snappuller. But I still get the following: 2007/10/29 11:16:01 started by 1001 2007/10/29 11:16:01 command: /opt/solr/bin/snapinstaller 2007/10/29 11:16:01 installing snapshot /opt/solr/data/snapshot.20071029111236 2007/10/29 11:16:01 notifing Solr to open a new Searcher 2007/10/29 11:16:01 failed to connect to Solr server 2007/10/29 11:16:01 snapshot installed but Solr server has not open a new Searcher 2007/10/29 11:16:01 failed (elapsed time: 0 sec) I have also confirmed with a whoami in crontab that the cron job is running as the same user as if running scripts by hand and as the user specified in scripts.conf. Do you know whey snapinstaller will not work within crontab but will work by hand ? Thanks Karen On Friday 26 October 2007 16:36:22 Yonik Seeley wrote: On 10/26/07, Karen Loughran [EMAIL PROTECTED] wrote: But after distribution of this latest snapshop to the slave the collection does not show the update (with solr admin query url or via java query client) UNLESS I restart tomcat ? Sounds like a config issue with the scripts... pulling the snapshot is obviously working, but snapinstaller (calling commit) is broken. try running bin/commit -V by hand on the slave -Yonik
field:(-null) returns records where field was not specified
Hi all, We are indexing different types of documents, some with certain fields set and some without, some fields sometimes in both. If a particular field is missing in a newly added record, I would have expected the query: field_name:(-null) not to return this particular record in the response, ie, I'm assuming the field is set to null. But the response we see includes empty docs: .. .. doc /doc doc /doc doc /doc etc, etc .. Can someone explain why field_name:(-null) returns the records where field_name is missing ? We note that if we do the range operation we can get a response without the records with no field_name: field_name:[* TO *] Many thanks Karen
Re: field:(-null) returns records where field was not specified
Hi Erik, thanks for your reply, I had read this page. But I'm not using the NOT operator, I'm using the - operator. I'm assuming there is a subtle difference between them in that NOT qualifies something else, hence needs 2 terms. Isn't the - operator supposed to be a complement to the + operator, ie. excludes something rather than requiring it ? thanks Karen On Monday 14 January 2008 15:14:05 Erick Erickson wrote: Have you seen this page? http://lucene.apache.org/java/docs/queryparsersyntax.html From that page: Note: The NOT operator cannot be used with just one term. For example, the following search will return no results: NOT jakarta apache Erick On Jan 14, 2008 9:30 AM, Karen Loughran [EMAIL PROTECTED] wrote: Hi all, We are indexing different types of documents, some with certain fields set and some without, some fields sometimes in both. If a particular field is missing in a newly added record, I would have expected the query: field_name:(-null) not to return this particular record in the response, ie, I'm assuming the field is set to null. But the response we see includes empty docs: .. .. doc /doc doc /doc doc /doc etc, etc .. Can someone explain why field_name:(-null) returns the records where field_name is missing ? We note that if we do the range operation we can get a response without the records with no field_name: field_name:[* TO *] Many thanks Karen
Re: field:(-null) returns records where field was not specified
Thanks Chris, this is useful, we can you the query format you suggest, Karen On Tuesday 15 January 2008 01:13:14 Chris Hostetter wrote: Several things in this thread should be clarified (note: order of quotations munged for clarity)... : I had read this page. But I'm not using the NOT operator, I'm using : the - operator. I'm assuming there is a subtle difference between them : in that NOT qualifies something else, hence needs 2 terms. Isn't the - : operator supposed to be a complement to the + operator, ie. excludes : something rather than requiring it ? The NOT operator and the - operator are in fact the same thing ... the duplicate syntax comes from Lucene trying to appease people that want boolean style operator synta (AND/OR/NOT) even though the query parser is not a boolean syntax. : Have you seen this page? : http://lucene.apache.org/java/docs/queryparsersyntax.html : : From that page: : Note: The NOT operator cannot be used with just one term. For example, : the following search will return no results: : NOT jakarta apache In Solr, the query parser can in fact support purely negative queries, by internally transforming the query, this is noted on the Solr query syntax wiki... http://wiki.apache.org/solr/SolrQuerySyntax : field_name:(-null) null is not a special keyword, if you look at the debugging output when doing that query you'll see that it is the same as: -field_name:null ... which is a search for all docs containing the string null in the field field_name. : The *:* (star colon star) means all records. The trick is to use (*:* : AND -field:[* TO *]). It's silly, but there it is. as i mentioned, you can do pure wildcard queries now, so a simple search for -field_name:[* TO *] will find all docs that have no indexed values for that field at all. : A performance note: we switched from empty fields to fields with a : standard 'empty' value. This way we don't have to do a range check to : find records with empty fields. Your milage may vary depending on how many docs you have with no value ... this also issn't practical when dealing with numeric, boolean, or date based fields. (and depending on how much churn there is in your index, the filterCache can probably make the difference negliable on average anyway). -Hoss
Restricted views of an index
Hi all, Is there any interest/activity for SOLR to provide a restricted view of an index, making only certain fields available/public, depending on the identity of the requesting client ? Certain information in our index is confidential and should only be accessible to certain individuals/groups, Thanks Karen
Re: Restricted views of an index
Thanks for the info Ryan Walter, We're looking into invariants and handler logic as you suggest, Karen On Friday 25 January 2008 15:55:09 Ryan McKinley wrote: Karen Loughran wrote: Hi all, Is there any interest/activity for SOLR to provide a restricted view of an index, making only certain fields available/public, depending on the identity of the requesting client ? Certain information in our index is confidential and should only be accessible to certain individuals/groups, The standard solr server relies on your servlet container for authentication/authorization. Using off the shelf stuff, you can use the 'invariants' param to limit what fields are available for a given handler. And then register different handlers to various paths with path based authentication. Does this make sense? You could also inject your authentication logic into custom RequestHandlers, UpdateProcessors, and/or SearchComponents ryan