bundled example appserver (Jetty vs Tomcat)

[Yonik Seeley <ys...@gmail.com>]

The servlet container we bundle for the example server, Jetty, is
turning out to have a number of bugs (or maybe just a few that
multiple people have all hit) in the new 6.0 line, and the 5.1
"stable" line.

Nice things about Jetty vs Tomcat:
  - very easy to start "java -jar start.jar", and more foolproof than
Tomcat since we rely on $cwd for the demo to find the solr home
"./solr"
  - fewer files, esp in bin... easier to understand what is needed and
what is not
  - log messages appear right on console, so errors are immediately
apparent.  You don't have to teach users how to go look through
multiple log files, and you don't have to teach them about shutting
down the server (just the normal CTRL-C)

Nice things about Tomcat 5.5 vs Jetty 5.1:
  - more stable!
  - doesn't require a JDK... can run with a JRE (Jetty6 could as well
since it uses JDT)
  - biggest user community, better docs, better support
  - slightly faster (in my micro benchmark sending deletes to Solr)

So, I'm obviously leaning toward Tomcat, esp if we can make it easy
enough for new users. Maybe make our own start script that calls
Tomcats (blech) and maybe tails a log file for better error
feedback???   Maybe it's just a matter of education/documentation,
esp in the tutorial?

No flame wars please ;-) (for people who don't follow the lucene dev
list, this is a reference to the current java5 discussion over there)

Thoughts?
-Yonik

Re: bundled example appserver (Jetty vs Tomcat)

[Bill Au <bi...@gmail.com>]

I am for replacing Jetty with Tomcat since Tomcat is more stable.
So when a trouble is reported we can concentrate on Solr itself rather
than also making sure the problem is not caused by Jetty.
Besides, it seems to be a number of folks are taking the example/tutorial
as is as a starting point and build upon it instead of deploying Solr into
their own container.  It will be a plus for those who are less familiar with
setting up a container.

Bill

On 6/20/06, Chris Hostetter <ho...@fucit.org> wrote:
>
>
> : bin/catalina.sh run, and you see the log messages in the current
> : window, and you can exit with CRTL-C.
> : So perhaps we could have our own start script that figured out the
> : current solr home, sets it via JAVA_OPTS, and calls "bin/catalina.sh
> : run"
>
> I dunno... it already bugs me a little that the example/tutorial rely on
> on sh/curl, and have to have that disclaimer about Cygwin that's made more
> then one person assume cygwin was required to use Solr on windows.  I've
> been thinking that once we figured out where/how to commit SOLR-20 it
> would be really nice to use "java -jar post.jar exampledocs/*"  instead of
> the current "sh exampledocs/post.sh exampledocs/*" ... adding another
> shell script just moves us away from that.
>
> .,.then again, having an example setup that breaks on non ascii characters
> and simple XML escaping is anoying too ...
>
> I guess I'm a +0 on the issue of switching to tomcat with a custom start
> script.
>
>
> -Hoss
>
>

Re: bundled example appserver (Jetty vs Tomcat)

[Chris Hostetter <ho...@fucit.org>]

: bin/catalina.sh run, and you see the log messages in the current
: window, and you can exit with CRTL-C.
: So perhaps we could have our own start script that figured out the
: current solr home, sets it via JAVA_OPTS, and calls "bin/catalina.sh
: run"

I dunno... it already bugs me a little that the example/tutorial rely on
on sh/curl, and have to have that disclaimer about Cygwin that's made more
then one person assume cygwin was required to use Solr on windows.  I've
been thinking that once we figured out where/how to commit SOLR-20 it
would be really nice to use "java -jar post.jar exampledocs/*"  instead of
the current "sh exampledocs/post.sh exampledocs/*" ... adding another
shell script just moves us away from that.

.,.then again, having an example setup that breaks on non ascii characters
and simple XML escaping is anoying too ...

I guess I'm a +0 on the issue of switching to tomcat with a custom start script.


-Hoss

Re: bundled example appserver (Jetty vs Tomcat)

[Yonik Seeley <ys...@gmail.com>]

On 6/20/06, Yoav Shapira <yo...@apache.org> wrote:
> - Relying on the current working directory (CWD) in any enterprise
> application is an evil on the same order as peppering your code with
> System.exit() calls.  Let's not do it in Solr, it's a very slippery
> slope.

We already have alternate ways of specifying the solr home which
contains the config... both through a system property, or through a
jndi lookup.

The problem has more to do with the included demo server... we don't
know the absolute path of anything, and we don't want people to have
to go and configure things just to start up a little demo.

> (Note this isn't specifically anti-Jetty, just let's not do
> this in general, and you noted Jetty allows this while Tomcat does
> not).

Tomcat does allow it, it's just easier to make a mistake.
The user could do "cd bin; ./startup.sh" instead of "./bin/startup.sh"
and mess up the CWD.

Tomcat also must make use of the CWD to set CATALINA_HOME if it's not set :-)

> - You can change the logging.properties that Tomcat uses to your
> heart's content, including enabling only a console logger or whatever.
>  It's pretty easy to do.

Actually, I just figured out that I could do
bin/catalina.sh run, and you see the log messages in the current
window, and you can exit with CRTL-C.
So perhaps we could have our own start script that figured out the
current solr home, sets it via JAVA_OPTS, and calls "bin/catalina.sh
run"

There should probably be comments in the start-script saying how that
isn't the recommended approach for production.


-Yonik

Re: bundled example appserver (Jetty vs Tomcat)

[Yoav Shapira <yo...@apache.org>]

Hi,
I'm biased towards Tomcat in this case for a couple of reasons, as
previously noted:

- It's an Apache product, and so is Solr.  Mortbay is nice about
Jetty, but it's a commercial enterprise and I would rather not depend
on it for anything as important as the default distro.  (Naturally,
I'm in favor of making it easy for users to plug in their servlet
container of choice in their own setup).

- Relying on the current working directory (CWD) in any enterprise
application is an evil on the same order as peppering your code with
System.exit() calls.  Let's not do it in Solr, it's a very slippery
slope.  (Note this isn't specifically anti-Jetty, just let's not do
this in general, and you noted Jetty allows this while Tomcat does
not).

- You can change the logging.properties that Tomcat uses to your
heart's content, including enabling only a console logger or whatever.
 It's pretty easy to do.

Costin (one of the Tomcat developers) has been working on essentially
a one jar version of Tomcat for 6.0, the next major Tomcat release.  I
don't speak for him, and I don't know its current status, but his
intent and plan was to make it possible to run Tomcat as "java -jar
tomcat.jar" and that's it.  It's not in Tomcat 5.5, heck it may never
be ready, but it's worth mentioning since you brought up the one-jar
point (which I agree is a very nice thing in Jetty).

And as you said, no flamewars.  I think Jetty and its developers are
cool, competent, I use it myself sometimes, have nothing against it.
But I think Tomcat is better for Solr as the example bundle for the
above reasons.

Yoav

Yoav

On 6/20/06, Yonik Seeley <ys...@gmail.com> wrote:
> The servlet container we bundle for the example server, Jetty, is
> turning out to have a number of bugs (or maybe just a few that
> multiple people have all hit) in the new 6.0 line, and the 5.1
> "stable" line.
>
> Nice things about Jetty vs Tomcat:
>   - very easy to start "java -jar start.jar", and more foolproof than
> Tomcat since we rely on $cwd for the demo to find the solr home
> "./solr"
>   - fewer files, esp in bin... easier to understand what is needed and
> what is not
>   - log messages appear right on console, so errors are immediately
> apparent.  You don't have to teach users how to go look through
> multiple log files, and you don't have to teach them about shutting
> down the server (just the normal CTRL-C)
>
> Nice things about Tomcat 5.5 vs Jetty 5.1:
>   - more stable!
>   - doesn't require a JDK... can run with a JRE (Jetty6 could as well
> since it uses JDT)
>   - biggest user community, better docs, better support
>   - slightly faster (in my micro benchmark sending deletes to Solr)
>
> So, I'm obviously leaning toward Tomcat, esp if we can make it easy
> enough for new users. Maybe make our own start script that calls
> Tomcats (blech) and maybe tails a log file for better error
> feedback???   Maybe it's just a matter of education/documentation,
> esp in the tutorial?
>
> No flame wars please ;-) (for people who don't follow the lucene dev
> list, this is a reference to the current java5 discussion over there)
>
> Thoughts?
> -Yonik
>


-- 
Yoav Shapira
Nimalex LLC
1 Mifflin Place, Suite 310
Cambridge, MA, USA
yoavs@computer.org / www.yoavshapira.com