Maybe this would be a nice extra hook to add to CoreContainer? We already have three per-container handlers defined in there (CoreAdminHandler, CollectionsHandler, InfoAdminHandler) which are instantiated the same way from solr.xml. We could extend this to allow other user-defined handlers which are started up and shut down with the container.
Alan Woodward www.flax.co.uk On 4 Feb 2014, at 15:48, Chris Hostetter wrote: > > There's really no generic place in solr to say "Here's an MBean, > instantiate it on startup so i can monitor it" ... all of the existing > monitoring & metrics reporting scaffolding is based arround the idea that > if there's a metric you want to monitor that metric *belongs* to something > that is useful for some reason (a request handler, a search component, > etc...) > > given the info you've provided, i think implementing a RequestHandler is > probably your best bet -- unless it's really important to you that it be a > singletome for the entire server, not per core: in which case you'd need > to configure a custom CoreAdminHandler and do your instantiation there. > > > : I've written a custom mbean that aggregates data from all the > : RequestHandler mbeans in a jvm to provide aggregate statistics for easier > : monitoring and currently I'm ensuring it gets ran by actually extending > : RequestHandlerBase and including the class as a request handler in > : solrconfig.xml. I don't think this is the ideal way of getting this code to > : run but as a quick hack it got the job done. If I wanted to ensure this > : class ran / register the mbean at a more appropriate place, earlier on in > : solr's initialization, where would that be? > > > -Hoss > http://www.lucidworks.com/ > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org >
