Re: Possible bug with searchers and core swapping
On 10/23/2015 5:27 PM, Shawn Heisey wrote: > Today I noticed this on my dev server running Solr 5.2.1: > > https://www.dropbox.com/s/bt81sv35acb7q2n/searcher-from-old-corename.png?dl=0 > On the index with the problem, I am using one third-party plugin with a > schema component and an update processor, and an update processor that I > wrote myself. Is it possible that these might be causing this to happen > if objects are not being closed properly? If I reload the core, then the extra searcher disappears. The problem persists after doing soft commits on the core, so a commit doesn't help. If I manually swap cores rather than doing it as part of a full index rebuild, this problem does not occur, which is very confusing. The problem happened on an index that has the custom components defined, but nothing in the index data actually triggers their use. I can try removing those components completely and rebuilding that index again. When it was running on Java 8, I grabbed a heap dump, but there's a bug in Eclipse MAT that prevents opening heap dumps created by Java 8, so I restarted with Java 7 and found the same problem after rebuilding the index. Now I have a heap dump that I can open in the Eclipse MemoryAnalyzer. If anyone knows how to find these Searcher objects in the MAT, I would appreciate knowing. The object I am currently looking for says "Searcher@3cd076ad[ai-0build] main" in the admin UI. There does not appear to be an object in the source code called "Searcher" so the Plugins/Stats page in the UI seems to be not reporting true object names. I think that's something that needs to be fixed. Thanks, Shawn
Possible bug with searchers and core swapping
Today I noticed this on my dev server running Solr 5.2.1: https://www.dropbox.com/s/bt81sv35acb7q2n/searcher-from-old-corename.png?dl=0 The name of this core is spark0live, but before the last index rebuild, it was named spark0build. My full rebuild process indexes data into build cores, then when the rebuild is done, it swaps the build cores with the live cores. This core is holding on to the searcher object from before the core swap. The last rebuild I did was days ago, so it was getting pretty old. A quick test on a 5.3.1 download (not a full test with my config/schema) did not reveal any problems. When I did some manual testing with core swaps on the 5.2.1 dev server, I could not reproduce the problem. On the index with the problem, I am using one third-party plugin with a schema component and an update processor, and an update processor that I wrote myself. Is it possible that these might be causing this to happen if objects are not being closed properly? I've since restarted the server, so I will need to initiate a full rebuild to see if the problem comes back. Thanks, Shawn
Re: solrcloud and core swapping
It doesn't matter which node you do it on. And, you can replace an existing alias by just creating another one with the same name. Upayavira On Mon, Aug 31, 2015, at 02:04 PM, Bill Au wrote: > Thank, Shawn. So I only need to issue the command to update the alias on > one of the node in the SolrCloud cluster, right? Should I do it on the > leader or it doesn't matter which node I do it one? > > Bill > > On Fri, Aug 28, 2015 at 10:35 AM, Shawn Heisey > wrote: > > > On 8/28/2015 8:25 AM, Shawn Heisey wrote: > > > Instead, use collection aliasing. Create collections named something > > > like foo_0 and foo_1, and update the alias "foo" to point to whichever > > > of them is currently live. Your queries and update requests will never > > > need to know about foo_0 and foo_1 ... only the coordinating part of > > > your system, where you would normally do your core swapping, needs to > > > know about those. > > > > You might also want to have a foo_build alias pointing to the *other* > > collection for any "full rebuild" functionality, so it can also use a > > static collection name. > > > > Thanks, > > Shawn > > > >
Re: solrcloud and core swapping
On 8/28/2015 8:25 AM, Shawn Heisey wrote: > Instead, use collection aliasing. Create collections named something > like foo_0 and foo_1, and update the alias "foo" to point to whichever > of them is currently live. Your queries and update requests will never > need to know about foo_0 and foo_1 ... only the coordinating part of > your system, where you would normally do your core swapping, needs to > know about those. You might also want to have a foo_build alias pointing to the *other* collection for any "full rebuild" functionality, so it can also use a static collection name. Thanks, Shawn
Re: solrcloud and core swapping
On 8/28/2015 8:10 AM, Bill Au wrote: > Is core swapping supported in SolrCloud? If I have a 5 nodes SolrCloud > cluster and I do a core swap on the leader, will the core be swapped on the > other 4 nodes as well? Or do I need to do a core swap on each node? When you're running SolrCloud, swapping any of the cores might really screw things up. I think it might be a good idea for Solr to return a "not supported in cloud mode" failure on certain CoreAdmin actions. Instead, use collection aliasing. Create collections named something like foo_0 and foo_1, and update the alias "foo" to point to whichever of them is currently live. Your queries and update requests will never need to know about foo_0 and foo_1 ... only the coordinating part of your system, where you would normally do your core swapping, needs to know about those. Thanks, Shawn
solrcloud and core swapping
Is core swapping supported in SolrCloud? If I have a 5 nodes SolrCloud cluster and I do a core swap on the leader, will the core be swapped on the other 4 nodes as well? Or do I need to do a core swap on each node? Bill
EmbeddedSolrServer, Indexing and Core Swapping
Hi I've switched my app to now use an EmbeddedSolrServer. I'm doing an index on my rebuild core and swapping cores at the end. Unfortunately, without restarting my web app I can't see the newly indexed data. I can see core swapping is working, and I can see the data after indexing without restarting servers if I use an http Solr server. Is there something different I need to do after indexing and swapping cores with an embedded Solr server? The only thing I can possibly think of is that when I create a EmbeddedSolrServer object for processing my swap request I need to specify a core. Don't know if this is significant. Also, do you think I need to recreate my CoreContainer? Any ideas would be welcome. Thanks
Re: Core Swapping
CoreAdmin is handled by /solr/admin/cores/ and not by
/solr/CORENAME/admin/cores/
On Tuesday 16 November 2010 16:17:34 Shaun Campbell wrote:
> I've got a Solr multi core system and I'm trying to swap the cores
> after a re-index via SolrJ using a separate HTTP Solr web server. My
> application seems to be generating a URL that's not valid for my Solr
> Tomcat installation but I can't see why or where it's getting its data
> from.
>
> Core swapping is working if I enter a URL manually into my browser.
> This URL works:
>
>
> http://localhost:8080/solr/admin/cores?action=SWAP&core=live&other=rebuild
>
> As you can see in my error below the URL generated
> (http://localhost:8080/solr/rebuild/admin/cores?action=SWAP&core=rebuild&ot
> her=live&wt=javabin&version=1) has the core *rebuild* in it. If I enter
> this directly into my
> browser I get the following error:
>
> HTTP Status 404 - /solr/admin/cores
> type Status report
> message /solr/admin/cores
> description The requested resource (/solr/admin/cores) is not available.
>
> My Java code is:
> CoreAdminRequest car = new CoreAdminRequest();
> car.setCoreName("rebuild");
> car.setOtherCoreName("live");
> car.setAction(CoreAdminParams.CoreAdminAction.SWAP);
> CoreAdminResponse carp = car.process(getSolrServer());
>
>
> Can anyone suggest what I might be doing wrong?
>
> Thanks
> Shaun
>
>
> The error from my web application is:
>
> SEVERE: Servlet.service() for servlet Spring MVC Dispatcher Servlet
> threw exception
> org.apache.solr.common.SolrException: Not Found
>
> Not Found
>
> request:
> http://localhost:8080/solr/rebuild/admin/cores?action=SWAP&core=rebuild&ot
> her=live&wt=javabin&version=1 at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHtt
> pSolrServer.java:435) at
> org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHtt
> pSolrServer.java:244) at
> org.apache.solr.client.solrj.request.CoreAdminRequest.process(CoreAdminReq
> uest.java:214) at
> uk.co.sjp.intranet.Factory.HttpSolrServerImpl.swapCores(HttpSolrServerImpl
> .java:50) at
> uk.co.sjp.intranet.indexing.DocumentIndexer.index(DocumentIndexer.java:185
> ) at uk.co.sjp.intranet.SearchController.test(SearchController.java:107) at
> sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at
> sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:
> 39) at
> sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorIm
> pl.java:25) at java.lang.reflect.Method.invoke(Method.java:597)
> at
> org.springframework.web.bind.annotation.support.HandlerMethodInvoker.doInv
> okeMethod(HandlerMethodInvoker.java:710) at
> org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invok
> eHandlerMethod(HandlerMethodInvoker.java:167) at
> org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdap
> ter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:414) at
> org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdap
> ter.handle(AnnotationMethodHandlerAdapter.java:402) at
> org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherSer
> vlet.java:771) at
> org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServ
> let.java:716) at
> org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkS
> ervlet.java:647) at
> org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.ja
> va:552) at javax.servlet.http.HttpServlet.service(HttpServlet.java:617) at
> javax.servlet.http.HttpServlet.service(HttpServlet.java:717) at
> org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(Applicati
> onFilterChain.java:290) at
> org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilter
> Chain.java:206) at
> org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatche
> r.java:630) at
> org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationD
> ispatcher.java:436) at
> org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispat
> cher.java:374) at
> org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatch
> er.java:302) at
> org.tuckey.web.filters.urlrewrite.NormalRewrittenUrl.doRewrite(NormalRewri
> ttenUrl.java:195) at
> org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:1
> 59) at
> org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:141) at
> org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.j
> ava:90) at
&
Core Swapping
I've got a Solr multi core system and I'm trying to swap the cores
after a re-index via SolrJ using a separate HTTP Solr web server. My
application seems to be generating a URL that's not valid for my Solr
Tomcat installation but I can't see why or where it's getting its data
from.
Core swapping is working if I enter a URL manually into my browser.
This URL works:
http://localhost:8080/solr/admin/cores?action=SWAP&core=live&other=rebuild
As you can see in my error below the URL generated
(http://localhost:8080/solr/rebuild/admin/cores?action=SWAP&core=rebuild&other=live&wt=javabin&version=1)
has the core *rebuild* in it. If I enter this directly into my
browser I get the following error:
HTTP Status 404 - /solr/admin/cores
type Status report
message /solr/admin/cores
description The requested resource (/solr/admin/cores) is not available.
My Java code is:
CoreAdminRequest car = new CoreAdminRequest();
car.setCoreName("rebuild");
car.setOtherCoreName("live");
car.setAction(CoreAdminParams.CoreAdminAction.SWAP);
CoreAdminResponse carp = car.process(getSolrServer());
Can anyone suggest what I might be doing wrong?
Thanks
Shaun
The error from my web application is:
SEVERE: Servlet.service() for servlet Spring MVC Dispatcher Servlet
threw exception
org.apache.solr.common.SolrException: Not Found
Not Found
request:
http://localhost:8080/solr/rebuild/admin/cores?action=SWAP&core=rebuild&other=live&wt=javabin&version=1
at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:435)
at
org.apache.solr.client.solrj.impl.CommonsHttpSolrServer.request(CommonsHttpSolrServer.java:244)
at
org.apache.solr.client.solrj.request.CoreAdminRequest.process(CoreAdminRequest.java:214)
at
uk.co.sjp.intranet.Factory.HttpSolrServerImpl.swapCores(HttpSolrServerImpl.java:50)
at
uk.co.sjp.intranet.indexing.DocumentIndexer.index(DocumentIndexer.java:185)
at uk.co.sjp.intranet.SearchController.test(SearchController.java:107)
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.springframework.web.bind.annotation.support.HandlerMethodInvoker.doInvokeMethod(HandlerMethodInvoker.java:710)
at
org.springframework.web.bind.annotation.support.HandlerMethodInvoker.invokeHandlerMethod(HandlerMethodInvoker.java:167)
at
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.invokeHandlerMethod(AnnotationMethodHandlerAdapter.java:414)
at
org.springframework.web.servlet.mvc.annotation.AnnotationMethodHandlerAdapter.handle(AnnotationMethodHandlerAdapter.java:402)
at
org.springframework.web.servlet.DispatcherServlet.doDispatch(DispatcherServlet.java:771)
at
org.springframework.web.servlet.DispatcherServlet.doService(DispatcherServlet.java:716)
at
org.springframework.web.servlet.FrameworkServlet.processRequest(FrameworkServlet.java:647)
at
org.springframework.web.servlet.FrameworkServlet.doGet(FrameworkServlet.java:552)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:617)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:290)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
org.apache.catalina.core.ApplicationDispatcher.invoke(ApplicationDispatcher.java:630)
at
org.apache.catalina.core.ApplicationDispatcher.processRequest(ApplicationDispatcher.java:436)
at
org.apache.catalina.core.ApplicationDispatcher.doForward(ApplicationDispatcher.java:374)
at
org.apache.catalina.core.ApplicationDispatcher.forward(ApplicationDispatcher.java:302)
at
org.tuckey.web.filters.urlrewrite.NormalRewrittenUrl.doRewrite(NormalRewrittenUrl.java:195)
at
org.tuckey.web.filters.urlrewrite.RuleChain.handleRewrite(RuleChain.java:159)
at org.tuckey.web.filters.urlrewrite.RuleChain.doRules(RuleChain.java:141)
at
org.tuckey.web.filters.urlrewrite.UrlRewriter.processRequest(UrlRewriter.java:90)
at
org.tuckey.web.filters.urlrewrite.UrlRewriteFilter.doFilter(UrlRewriteFilter.java:417)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:206)
at
uk.co.sjp.intranet.utils.JsonpCallbackFilter.doFilter(JsonpCallbackFilter.java:108)
at
org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:235)
at
org.apache.
