[
https://issues.apache.org/jira/browse/SOLR-2623?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13058112#comment-13058112
]
Hoss Man commented on SOLR-2623:
--------------------------------
Alexey: at first glance, i think i would prefer Shalin's suggestion over your
patch.
My main hesitation about your approach is the parameterized close method -- If
we really go that route i'd much rather see something like a
"SolrCore.preCloseToReleaesResources()" method. But more fundementally, if we
unregister the MBeans before creating the new core, there is a window of time
when the old core is responding to requests, but can't be monitored (and if
anything goes wrong with creating the new core, the old one will continue to
handle requests indefinitely but be totally unmonitorable.
That said: i suspect the fix might even be easier then what Shalin proposed
(which would require making SolrCore passing itself into the JmxMonitoredMap)
... can't we essentially change
JmxMonitoredMap.unregsiter(String,SolrInfoMBean) to have psuedo code like this..
{code}
if (server.isRegistered(name)) {
MBean existing = server.getMBean(name)
if (existing intsanceof SolrDynamicMBean &&
existing.getSolrInfoMBean() == this.get(name)) {
server.unregisterMBean(name);
} else {
// :NOOP: MBean is not ours
}
}
{code}
...adding a package protected SolrDynamicMBean.getSolrInfoMBean() seems less
invasive then passing the SolrCore to another class
> Solr JMX MBeans do not survive core reloads
> -------------------------------------------
>
> Key: SOLR-2623
> URL: https://issues.apache.org/jira/browse/SOLR-2623
> Project: Solr
> Issue Type: Bug
> Components: multicore
> Affects Versions: 1.4, 1.4.1, 3.1, 3.2
> Reporter: Alexey Serba
> Assignee: Shalin Shekhar Mangar
> Priority: Minor
> Attachments: SOLR-2623.patch, SOLR-2623.patch, SOLR-2623.patch
>
>
> Solr JMX MBeans do not survive core reloads
> {noformat:title="Steps to reproduce"}
> sh> cd example
> sh> vi multicore/core0/conf/solrconfig.xml # enable jmx
> sh> java -Dcom.sun.management.jmxremote -Dsolr.solr.home=multicore -jar
> start.jar
> sh> echo 'open 8842 # 8842 is java pid
> > domain solr/core0
> > beans
> > ' | java -jar jmxterm-1.0-alpha-4-uber.jar
> ....
> solr/core0:id=core0,type=core
> solr/core0:id=org.apache.solr.handler.StandardRequestHandler,type=org.apache.solr.handler.StandardRequestHandler
> solr/core0:id=org.apache.solr.handler.StandardRequestHandler,type=standard
> solr/core0:id=org.apache.solr.handler.XmlUpdateRequestHandler,type=/update
> solr/core0:id=org.apache.solr.handler.XmlUpdateRequestHandler,type=org.apache.solr.handler.XmlUpdateRequestHandler
> ...
> solr/core0:id=org.apache.solr.search.SolrIndexSearcher,type=searcher
> solr/core0:id=org.apache.solr.update.DirectUpdateHandler2,type=updateHandler
> sh> curl 'http://localhost:8983/solr/admin/cores?action=RELOAD&core=core0'
> sh> echo 'open 8842 # 8842 is java pid
> > domain solr/core0
> > beans
> > ' | java -jar jmxterm-1.0-alpha-4-uber.jar
> # there's only one bean left after Solr core reload
> solr/core0:id=org.apache.solr.search.SolrIndexSearcher,type=Searcher@2e831a91
> main
> {noformat}
> The root cause of this is Solr core reload behavior:
> # create new core (which overwrites existing registered MBeans)
> # register new core and close old one (we remove/un-register MBeans on
> oldCore.close)
> The correct sequence is:
> # unregister MBeans from old core
> # create and register new core
> # close old core without touching MBeans
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org
For additional commands, e-mail: dev-h...@lucene.apache.org
