Re: Extending Solr's Admin functionality
On Sep 23, 2006, at 3:57 PM, Otis Gospodnetic wrote: How about another approach - expose all Solr admin data via HTTP/ XML, just like it's done with search requests? i think that would be fantastic. thinking of solr as a hard core service above and beyond lucene exposing all of its internals via request handlers is the way to go. having the schema and solrconfig files exposed opens interesting possibilities for a client to introspect solr to that degree already, but even more so exposing text analysis tools like analysis.jsp, spell checking and highlighting services, and including all the stats data for the caches. yeah! i'm +1. the inevitable question is where does security fit into the picture. solr has a couple of options for that without making things complicated: * secure solr behind a firewall that is only open to your front- end application * configuring the request handlers in solrconfig.xml (or by default not opening admin ones unless you uncomment example configuration) so clients have a narrowing view of the solr system (heh) than it allows (like decommissioning Pluto) i think solr probably ought to up front mention all the security options currently available and cut to the chase on why anything more sophisticated is out of its scope. perhaps some authentication/ authorization as well as HTTPS should eventually make it into the core, but getting more fine grained is unnecessary. thoughts? Erik
Re: Extending Solr's Admin functionality
I followed the discussion the last 3 day and I still wondering why nobody turned up with an integration of solr monitoring and administration functionality using javas fantastic management extension JMX. I joined a team 2 years ago building a distributed webspider / searcher (similar to nutch). In the middle of the development process someone came up with monitoring the system via the admin frontend which communicates via http with the indexer, spider and searcher part of the system. At that time I was playing arround with jmx building a generic server side monitoring app. and suggested to use JMX for all the monitoring. It turned out in a very handy and easy to use solution. This would also solve a couple of problems about blowing up the core with extra features if you create the jmx monitoring in a extra jar as a contrib feature. You wouldn't need to write a frontend neither and everybody who is used to his JMX Monitoring frontend could use it to monitor solr as well. Loading custom classes and monitor the desired behaviour might be much easier to implement and to analyze. Additionally jmx supports memory behaviour monitoring with java 1.5. Another feature is triggering some messages to global monitoring systems if errors or undesired behaviour of managed components occur which could also be exposed via JMX. Also security / firewall doubts would not concern the core and its security as jmx connectors can be blocked by firewalls not using the same port as solr does (no matter which protocol is used to connect to the server). As I'm not very familiar with the solr core I spotted some Info MBeans in solr which would be accessible without writing any code as well. After all I do have to admin that accessing all these features via JMX would not be as user friendly as a hand made http frontend would be but I a search server admin / manage frontend exposed to people without any background?! I would also be happy to contribute my experience with JMX to the project. best regards Simon
Re: Extending Solr's Admin functionality
On 9/24/06, Erik Hatcher <[EMAIL PROTECTED]> wrote: ...perhaps some authentication/ authorization as well as HTTPS should eventually make it into the core, but getting more fine grained is unnecessary... If meaningful URLs are used (admin/stats, admin/config, admin/analysis, etc.), it is relatively easy to use either the servlet container or something like mod_proxy to implement security. Designing a good URL scheme might remove the need to address security concerns at the Solr level. -Bertrand
Re: Extending Solr's Admin functionality
On Sep 24, 2006, at 3:09 PM, Bertrand Delacretaz wrote: On 9/24/06, Erik Hatcher <[EMAIL PROTECTED]> wrote: ...perhaps some authentication/ authorization as well as HTTPS should eventually make it into the core, but getting more fine grained is unnecessary... If meaningful URLs are used (admin/stats, admin/config, admin/analysis, etc.), it is relatively easy to use either the servlet container or something like mod_proxy to implement security. Designing a good URL scheme might remove the need to address security concerns at the Solr level. Agreed. Perhaps the Solr servlet should use the path information for selecting the request handler: /solr/search/standard, /solr/search/ mlt, /solr/search/dismax, etc. And a /admin, /stats, and/or a /tools paths would be a good separation. /tools/analyzer, /stats/cache... Erik
Re: Extending Solr's Admin functionality
I certainly agree that a JMX interface into Solr would be nice to have. [a different topic: I've also been thinking Solr under NetKernel would be a nice fit also] On Sep 24, 2006, at 3:12 PM, Simon Willnauer wrote: Also security / firewall doubts would not concern the core and its security as jmx connectors can be blocked by firewalls not using the same port as solr does (no matter which protocol is used to connect to the server). I still think exposing the internals of caching data, text analysis, and other features later like spell checking (so only available terms are suggested) makes sense and just as valuable as search and facet results currently. That information could be exposed easily through request handlers. As I'm not very familiar with the solr core I spotted some Info MBeans in solr which would be accessible without writing any code as well. After all I do have to admin that accessing all these features via JMX would not be as user friendly as a hand made http frontend would be but I a search server admin / manage frontend exposed to people without any background?! I think the majority of the clients for Solr will be non-Java, so while a JMX interface would be valuable to some it wouldn't be as generally useful to the majority of Solr users (my hunch). I would also be happy to contribute my experience with JMX to the project. But don't let that deter you. JMX is cool stuff. Erik
