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
> 

Reply via email to