> I would go down the route and would supply Solr with a high-performance > network layer (like netty) without any Servlet Crap.
Yea, that would certainly be an interesting path to explore and a more attractive way to morph Solr into a standalone server than being a Jetty-only webapp. It would probably simplify and speed many things up but also open up another box of problems. But I can't help to think it would be cool to be able to ssh into a Solr server and do stuff through a CLI :) But as it is now, Solr *is* a web-app and that has its benefits in that we concentrate on the search features, not the deployment ; and large organizations already know how to deploy, configure and monitor their favorite app-server, so Solr is just another use case. One of my customers use Resin for all their webapps, and also run Solr in Resin, reusing their IT dept's best practice deployment and security stuff. They also needed certificate based authentication and encryption on all traffic to the Solr servers since their index contains sensitive docs, so they added HTTPS with certificates easily since they knew the Resin container already. -- Jan Høydahl, search solution architect Cominvent AS - www.cominvent.com Solr Training - www.solrtraining.com On 13. juli 2012, at 17:56, Uwe Schindler wrote: > In addition: > Solr is *not* and J2EE application! It just uses the servlet container to > have a connection to outside. Installing Solr is JBoss or any other full > fledged J2EE container is a waste of resources and controllability. > > I would go down the route and would supply Solr with a high-performance > network layer (like netty) without any Servlet Crap. We don’t use anything > from Servlet contains, only some very limited entry points to get the > requests from the network mapped to our handlers (RequestHandlers are already > half of a HTTP server, because we don’t use any features for mapping Requests > to handlers any J2EE container would provide). > > Solr is a server and not a webapp. Do you install MySQL inside a servlet > container? Do you install PostgreSQL inside a servlet Container? Do you > install *foobar* inside a Servlet Container if it’s a database-like server? > NO! - As so Solr. Solr, like ElasticSearch (which does not use servlets) is a > server and you run it from command line or init.d/upstart scripts like any > other database server. > > Uwe > > ----- > Uwe Schindler > H.-H.-Meier-Allee 63, D-28213 Bremen > http://www.thetaphi.de > eMail: u...@thetaphi.de > > >> -----Original Message----- >> From: Robert Muir [mailto:rcm...@gmail.com] >> Sent: Friday, July 13, 2012 5:48 PM >> To: dev@lucene.apache.org >> Subject: Re: [Discuss] Should Solr be an AppServer agnostic WAR or require >> Jetty? >> >> On Fri, Jul 13, 2012 at 11:37 AM, Dyer, James <james.d...@ingrambook.com> >> wrote: >>> On the other hand, expecting to test every possible container before you can >> tell people its "supported" for a standards-compliant java web-app is just >> crazy. >> This is like saying that DIH's SQLEntityProcessor is only supported for >> HSQLDB >> because that's the one we test against, or that you can't run Lucene on >> Solaris >> because Uwe's Jenkins doesn't have a Solaris environment. >>> >> >> I don't think its crazy at all. Just like TimeZone/Codec/Locale/Directory >> impl, if >> Solr should be agnostic to it, then the test framework should rotate between >> different implementations and pass. >> >> As far as Lucene, we try to do this, sure we didnt have a Windows jenkins >> until >> recently, but we at least simulate its crazy filesystem semantics in all >> tests via >> MockDirectoryWrapper. >> >> Not even trying to do this kinda testing for anything but jetty = not >> supported. >> >> -- >> lucidimagination.com >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional >> commands, e-mail: dev-h...@lucene.apache.org > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org > For additional commands, e-mail: dev-h...@lucene.apache.org > --------------------------------------------------------------------- To unsubscribe, e-mail: dev-unsubscr...@lucene.apache.org For additional commands, e-mail: dev-h...@lucene.apache.org
