Lajos, Just did a quick test on 4.6.1 UNLOADing a SolrCloud replica using the core admin API and it worked as expected. I'm running with the core.properties setup. Are you running with an old style solr.xml?
The org.apache.solr.core.CorePropertiesLocator.delete() method in trunk and 4x are protecting against an NPE. In 4.6 and 4.6.1 the NPE check is not present. So the issue may be resolved in trunk and 4x. Joel Bernstein Search Engineer at Heliosearch On Thu, Feb 13, 2014 at 7:06 PM, Lajos <la...@protulae.com> wrote: > Hi all, > > I just want to verify that it is no longer possible to unload a Cloud core > via the Core API UNLOAD command, correct? > > I had two situations: one where I wanted to remove old replicas in a node > that I was deactivating (and I had already created new replicas) and one > where I needed to remove a shard I split. > > In both cases I got this nice stack trace: > > <response> > <lst name="responseHeader"><int name="status">500</int><int > name="QTime">1</int></lst><lst name="error"><str name="trace">java.lang. > NullPointerException > at org.apache.solr.core.CorePropertiesLocator.delete( > CorePropertiesLocator.java:95) > at org.apache.solr.core.CoreContainer.remove( > CoreContainer.java:754) > at org.apache.solr.handler.admin.CoreAdminHandler. > handleUnloadAction(CoreAdminHandler.java:589) > at org.apache.solr.handler.admin.CoreAdminHandler. > handleRequestBody(CoreAdminHandler.java:162) > at org.apache.solr.handler.RequestHandlerBase.handleRequest( > RequestHandlerBase.java:135) > at org.apache.solr.servlet.SolrDispatchFilter.handleAdminRequest( > SolrDispatchFilter.java:662) > at org.apache.solr.servlet.SolrDispatchFilter.doFilter( > SolrDispatchFilter.java:248) > at org.apache.solr.servlet.SolrDispatchFilter.doFilter( > SolrDispatchFilter.java:197) > at org.apache.catalina.core.ApplicationFilterChain. > internalDoFilter(ApplicationFilterChain.java:243) > at org.apache.catalina.core.ApplicationFilterChain.doFilter( > ApplicationFilterChain.java:210) > at org.apache.catalina.core.StandardWrapperValve.invoke( > StandardWrapperValve.java:222) > at org.apache.catalina.core.StandardContextValve.invoke( > StandardContextValve.java:123) > at org.apache.catalina.core.StandardHostValve.invoke( > StandardHostValve.java:171) > at org.apache.catalina.valves.ErrorReportValve.invoke( > ErrorReportValve.java:100) > at org.apache.catalina.valves.AccessLogValve.invoke( > AccessLogValve.java:953) > at org.apache.catalina.core.StandardEngineValve.invoke( > StandardEngineValve.java:118) > at org.apache.catalina.connector.CoyoteAdapter.service( > CoyoteAdapter.java:408) > at org.apache.coyote.http11.AbstractHttp11Processor.process( > AbstractHttp11Processor.java:1041) > at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler. > process(AbstractProtocol.java:603) > at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor. > run(JIoEndpoint.java:310) > at java.util.concurrent.ThreadPoolExecutor$Worker. > runTask(ThreadPoolExecutor.java:895) > at java.util.concurrent.ThreadPoolExecutor$Worker.run( > ThreadPoolExecutor.java:918) > at java.lang.Thread.run(Thread.java:662) > </str><int name="code">500</int></lst> > </response> > > I had to resort to DELETEREPLICA, which worked fine, but I just wanted to > verify whether this is a bug or intended behavior. Lots of older docs say > to use UNLOAD for these situations. > > Thanks, > > Lajos > >
