lucene-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jan Høydahl <jan....@cominvent.com>
Subject Re: [Discuss] Should Solr be an AppServer agnostic WAR or require Jetty?
Date Fri, 13 Jul 2012 23:42:32 GMT
> 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: uwe@thetaphi.de
> 
> 
>> -----Original Message-----
>> From: Robert Muir [mailto:rcmuir@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.Dyer@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-unsubscribe@lucene.apache.org For additional
>> commands, e-mail: dev-help@lucene.apache.org
> 
> 
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
> For additional commands, e-mail: dev-help@lucene.apache.org
> 


---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@lucene.apache.org
For additional commands, e-mail: dev-help@lucene.apache.org


Mime
View raw message