Re: Re: >> Apache/Tomcat Collaboration

["Shailesh S. Gokhale" <ss...@rediffmail.com>]

Hi Justin!
Thanks a lot for your answer. But I would like to paste the relevant part of the docs (Tomcat-A Minimilistic Users Guide) from the 'Getting Started' section.

--- Start ---
Getting Started

Tomcat is a servlet container with a JSP environment. A servlet container is a runtime shell that manages and invokes servlets on behalf of users.

You can roughly partition servlet containers into:

1. Stand-alone servlet containers
These are an integral part of the web server. This is the case when using a Java-based web server, for example the servlet container that is part of the JavaWebServer. Stand-alone is the default mode used by Tomcat.
Most web servers, however, are not Java-based, which leads us to the next two container types. 
2. In-process servlet containers
The servlet container is a combination of a web server plugin and a Java container implementation. The web server plugin opens a JVM inside the web server's address space and lets the Java container run in it. If a certain request should execute a Servlet, the plugin takes control over the request and passes it (using JNI) to the Java container. An in-process container is suitable for multi-threaded single-process servers and provides good performance but is limited in scalability. 
3. Out-of-process servlet containers
The servlet container is a combination of a web server plugin and a Java container implementation that runs in a JVM outside the web server. The web server plugin and the Java container JVM communicate using some IPC mechanism (usually TCP/IP sockets). If a certain request should execute a Servlet the plugin takes control over the request and passes it (using the IPCs) to the Java container. The response time of an out-of-process engine is not as good as in the in-process one but the out-of-process engine performs better in many measurable ways (scalability, stability, etc.). 

***
Tomcat can be used as either a stand-alone container (mainly for development and debugging) or as an add-on to an existing web server (currently Apache, IIS and Netscape servers are supported). This means that whenever you are deploying Tomcat you will have to decide how to use it and, *** if you select options 2 or 3, you will also need to install a web server adapter ***
***

--- End ---
Please reply if I understand the marked portion (above) wrongly.

Many Thanks
Shailesh

On Sun, 30 Sep 2001 Justin Erenkrantz wrote :
> On Sun, Sep 30, 2001 at 01:46:37PM -0000, Shailesh S. 
> Gokhale wrote:
> > 1. I understand that Tomcat can work with any 
> (supported) web 
> > server in two modes - 'In Proc' and 'Out of Proc'. I 
> have 
> > successfully configured Tomcat (Out of Proc) to work 
> with Apache. 
> > The question is how can I make it work 'In Proc' with 
> Apache? 
> 
> I'm not aware how Apache will load the JVM, so I don't 
> see how you
> will get it to be "in proc."  AFAIK, all of the modules 
> for all
> webservers require an externally running copy of 
> Tomcat.  I could
> be wrong though.  I think some of them are smart enough 
> to invoke
> Tomcat if it isn't running, but that doesn't mean they 
> are running
> in the same process space.
> 
> > 2. In relation to the above, there seem to be two 
> available 
> > adapters for the Apache/Tomcat collaboration in the 
> Windows 
> > environment. One is ApacheModuleJServ.dll and another 
> is 
> > mod_jk.dll. [The second one replaces a more complex 
> adapter 
> > (mod_jserv.dll) available earlier and no longer used]
> . My 
> > question is what is the difference between the two - 
> that is 
> > ApacheModuleJServ.dll and mod_jk.dll? 
> 
> I think ApacheModuleJServ.dll is just a renamed version 
> of
> mod_jserv.dll.  You should always be using mod_jk - 
> mod_jserv
> isn't supported anymore.  -- justin
> 
 

Re: Re: >> Apache/Tomcat Collaboration

[cm...@yahoo.com]

On Mon, 1 Oct 2001, Aaron Bannert wrote:

> > Right now the 'integration' between tomcat and apache is in a very
> > bad shape, the web server is used mostly as a proxy ( that adds a
> > significant overhead, apache+tomcat can be slower than tomcat standalone),
> > and to servle static files ( that are not password protected ).
> > Authentication can be done only by tomcat, and having apache send messages
> > to tomcat to authenticate for static pages would kill any performance.
>
> In many cases I've seen, apache isn't even being used to serve static
> content from the java webapps. OTOH, I think we could come up with a better
> way to map tomcat's static content to the virtual URI-space of apache to
> encourage this more.

I know - anything that has a security-constraint ( or filter for 2.3 )
has to be sent to tomcat, since authentication is not integrated (and
filters are ... well, nightmares ).
Even for normal static pages - the apache configuration to do that is
quite complex - and I'm not only talking about users, but for us too.
Generating the config or sending it via wire does simplify the user's
life, but the problem is that we have many unsolved problems.


> > In general, tomcat can't benefit from most of the features the web server
> > provides, and the web server can't benefit from any feature that tomcat
> > provides.
>
> I have to disagree with this. In general I think we're all much more
> comfortable using apache-httpd's HTTP parsing routines, if not merely
> for the fact that they are tried and tested (not to mention, in many
> cases implemented by the spec author). Tomcat can and should take advantage
> of this. In addition, the huge collection of httpd modules can be of huge
> value to tomcat. The biggest problem I'm seeing here is integration.

Well, I was just stating the current reality - of course tomcat should
take advantage of this. Integrating with the large collection of modules
is one of the big benefits of in-process - and it's a 2-way street.
The only problem - it's not yet completed, and there are many problems
due to 'impedance mismatch'.


> > And the difference between a method call ( even via JNI ) and
> > IPC - it's pretty significant. But that's nothing compared with
> > the fact that via JNI you can avoid a lot of memcopy, use existing
> > ( and optimized ) methods, have access to a powerfull API,
> > hook deeply into apache.
>
> I agree that there is a potential bottleneck in remote IPC that can be
> avoided with things like JNI. However, I don't think that JNI has better
> access to the httpd internals than any other apache module.

No, the point is that tomcat can use JNI to access the httpd internals
_like_ any other apache module. Most of the 'internals' are not
designed for remote access ( i.e. low latency, etc ) via IPC.


> The concern I have with robustness of the VM isn't the VM itself, but the
> 3rd party jars that are used in most webapps. One of those modules causes
> a segfault in the multiprocess model and apache/tomcat just keep on chugging.
> If you have a segfault in one of the multithreaded models, you end up losing
> all the threads in that process -- even if they are in the middle of a
> healthy connection. (Apache will have this same problem, so it's not specific
> to tomcat)

No java code should be able to segfault the VM - regardless of what you do
inside ( except for calling JNI - but that's not available to users, it's
just a small layer in tomcat's internal implementation ).
If you get a recent VM - you shouldn't have crashes ( at least it's a long
time since I got a crash - and that was in a GUI application ).

Of course, everything has a price - and it's important to have multiple
choices :-) And you can configure jk for something in the middle -
like use JNI for the most accessed pages and IPC for everything else.
Or just use IPC for pages - but JNI for integration ( i.e.
authentication, etc).

Costin

Re: Re: >> Apache/Tomcat Collaboration

[Aaron Bannert <aa...@clove.org>]

On Mon, Oct 01, 2001 at 12:10:36PM -0700, cmanolache@yahoo.com wrote:
> On Mon, 1 Oct 2001, Aaron Bannert wrote:
> 
> > What are the main advantages to using an in-process VM as opposed
> > to an out-of-process VM bridged over some form of IPC (like
> > mod_webapp/mod_jk/mod_jserv)?
> 
> Well, using in-process VM ( like mod_jk ) has many more benefits than
> just reduced request/response latency.

Agreed.

> Think about mod_perl - it's not just about 'faster CGIs'.
> 
> Right now the 'integration' between tomcat and apache is in a very
> bad shape, the web server is used mostly as a proxy ( that adds a
> significant overhead, apache+tomcat can be slower than tomcat standalone),
> and to servle static files ( that are not password protected ).
> Authentication can be done only by tomcat, and having apache send messages
> to tomcat to authenticate for static pages would kill any performance.

In many cases I've seen, apache isn't even being used to serve static
content from the java webapps. OTOH, I think we could come up with a better
way to map tomcat's static content to the virtual URI-space of apache to
encourage this more.

> In general, tomcat can't benefit from most of the features the web server
> provides, and the web server can't benefit from any feature that tomcat
> provides.

I have to disagree with this. In general I think we're all much more
comfortable using apache-httpd's HTTP parsing routines, if not merely
for the fact that they are tried and tested (not to mention, in many
cases implemented by the spec author). Tomcat can and should take advantage
of this. In addition, the huge collection of httpd modules can be of huge
value to tomcat. The biggest problem I'm seeing here is integration.

> And the difference between a method call ( even via JNI ) and
> IPC - it's pretty significant. But that's nothing compared with
> the fact that via JNI you can avoid a lot of memcopy, use existing
> ( and optimized ) methods, have access to a powerfull API,
> hook deeply into apache.

I agree that there is a potential bottleneck in remote IPC that can be
avoided with things like JNI. However, I don't think that JNI has better
access to the httpd internals than any other apache module.

> > I would imagine request/response latency is reduced, but how well does
> > it scale, and how does it deal with issues of robustness?
> 
> It doesn't scale very well in a multi-process model, and it's as robust as
> the Java VM. The main problem with multi-process model is the sessions.
> But that can be resolved ( especially if you take advantage of mmap ),
> and you still gain a lot from the deep integration.

Apache 2.0 will offer a few alternatives to the multi-process (aka
prefork) model, two of which are multi-threaded, multi-process models. You
may want to look into this (perhaps having one multithreaded JNI-wrapper
per process). If anything, the newer models will give you many more variables
to play with.

The concern I have with robustness of the VM isn't the VM itself, but the
3rd party jars that are used in most webapps. One of those modules causes
a segfault in the multiprocess model and apache/tomcat just keep on chugging.
If you have a segfault in one of the multithreaded models, you end up losing
all the threads in that process -- even if they are in the middle of a
healthy connection. (Apache will have this same problem, so it's not specific
to tomcat)

-aaron

Re: "Unsubscribe"

[Bojan Smojver <bo...@binarix.com>]

Try: http://jakarta.apache.org/site/mail2.html

Bojan

Sai Sekhar wrote:
> 
> "Unsubscribe"

"Unsubscribe"

[Sai Sekhar <sa...@yahoo.com>]

"Unsubscribe"










--- Christopher Cain <cc...@mhsoftware.com> wrote:
> Quoting Bojan Smojver <bo...@binarix.com>:
> 
> > Christopher Cain wrote:
> > > 
> > > I was thinking that maybe we could actually
> start running Tomcat
> > inside the
> > > kernel process itself. It worked for IIS ...
> > 
> > Where IIS stands for: Internet Infected Server.
> 
> haha ... I like that one. I'll have to remember that
> one the next time an IIS 
> worm makes the rounds. In fact, aren't we overdue
> for the next one already? 
> What time is it right now? ;-)
> 
> - Christopher
> 
> /**
>  * Pleurez, pleurez, mes yeux, et fondez vous en
> eau!
>  * La moiti� de ma vie a mis l'autre au tombeau.
>  *    ---Corneille
>  */


__________________________________________________
Do You Yahoo!?
NEW from Yahoo! GeoCities - quick and easy web site hosting, just $8.95/month.
http://geocities.yahoo.com/ps/info1

Re: >> Apache/Tomcat Collaboration

[Christopher Cain <cc...@mhsoftware.com>]

Quoting Bojan Smojver <bo...@binarix.com>:

> Christopher Cain wrote:
> > 
> > I was thinking that maybe we could actually start running Tomcat
> inside the
> > kernel process itself. It worked for IIS ...
> 
> Where IIS stands for: Internet Infected Server.

haha ... I like that one. I'll have to remember that one the next time an IIS 
worm makes the rounds. In fact, aren't we overdue for the next one already? 
What time is it right now? ;-)

- Christopher

/**
 * Pleurez, pleurez, mes yeux, et fondez vous en eau!
 * La moitié de ma vie a mis l'autre au tombeau.
 *    ---Corneille
 */

Re: >> Apache/Tomcat Collaboration

[Bojan Smojver <bo...@binarix.com>]

Christopher Cain wrote:
> 
> Quoting cmanolache@yahoo.com:
> 
> > On Mon, 1 Oct 2001, Aaron Bannert wrote:
> >
> > > What are the main advantages to using an in-process VM as opposed
> > > to an out-of-process VM bridged over some form of IPC (like
> > > mod_webapp/mod_jk/mod_jserv)?
> >
> > Well, using in-process VM ( like mod_jk ) has many more benefits than
> > just reduced request/response latency.
> 
> I was thinking that maybe we could actually start running Tomcat inside the
> kernel process itself. It worked for IIS ...

Where IIS stands for: Internet Infected Server.

Bojan

Re: Re: >> Apache/Tomcat Collaboration

[Christopher Cain <cc...@mhsoftware.com>]

Quoting cmanolache@yahoo.com:

> On Mon, 1 Oct 2001, Aaron Bannert wrote:
> 
> > What are the main advantages to using an in-process VM as opposed
> > to an out-of-process VM bridged over some form of IPC (like
> > mod_webapp/mod_jk/mod_jserv)?
> 
> Well, using in-process VM ( like mod_jk ) has many more benefits than
> just reduced request/response latency.

I was thinking that maybe we could actually start running Tomcat inside the 
kernel process itself. It worked for IIS ...

... until the latest generation of worm authors remembered that something 
running in the kernel space has all sorts of fun permissions to the entire 
filesystem. Now *that's* In-Process, baby!

Just a little Monday humor :)

- Christopher

/**
 * Pleurez, pleurez, mes yeux, et fondez vous en eau!
 * La moitié de ma vie a mis l'autre au tombeau.
 *    ---Corneille
 */

Re: Re: >> Apache/Tomcat Collaboration

[cm...@yahoo.com]

On Mon, 1 Oct 2001, Aaron Bannert wrote:

> What are the main advantages to using an in-process VM as opposed
> to an out-of-process VM bridged over some form of IPC (like
> mod_webapp/mod_jk/mod_jserv)?

Well, using in-process VM ( like mod_jk ) has many more benefits than
just reduced request/response latency.

Think about mod_perl - it's not just about 'faster CGIs'.

Right now the 'integration' between tomcat and apache is in a very
bad shape, the web server is used mostly as a proxy ( that adds a
significant overhead, apache+tomcat can be slower than tomcat standalone),
and to servle static files ( that are not password protected ).
Authentication can be done only by tomcat, and having apache send messages
to tomcat to authenticate for static pages would kill any performance.

In general, tomcat can't benefit from most of the features the web server
provides, and the web server can't benefit from any feature that tomcat
provides.

And the difference between a method call ( even via JNI ) and
IPC - it's pretty significant. But that's nothing compared with
the fact that via JNI you can avoid a lot of memcopy, use existing
( and optimized ) methods, have access to a powerfull API,
hook deeply into apache.

> I would imagine request/response latency is reduced, but how well does
> it scale, and how does it deal with issues of robustness?

It doesn't scale very well in a multi-process model, and it's as robust as
the Java VM. The main problem with multi-process model is the sessions.
But that can be resolved ( especially if you take advantage of mmap ),
and you still gain a lot from the deep integration.



Costin

Re: Re: >> Apache/Tomcat Collaboration

[Aaron Bannert <aa...@clove.org>]

On Mon, Oct 01, 2001 at 02:06:02AM -0700, cmanolache@yahoo.com wrote:
> Well, I had it working for a while, now it crashes with some VMs.
> It's a tricky thing - usually the signals are the biggest problem, java
> is very sensitive.
> 
> Nothing special - just compile jk with support for jni worker, and
> follow the instructions. You may need to set LD_LIBRARY_PATH to
> include all the .so from java, and you may have problems with some
> VMs - JDK1.2.2 seems the easiest to get working, and surprisingly
> 1.4 worked also fine ( I'm talking about Linux versions here ).
> 
> It's tricky, but I think it's worth it.

What are the main advantages to using an in-process VM as opposed
to an out-of-process VM bridged over some form of IPC (like
mod_webapp/mod_jk/mod_jserv)?

I would imagine request/response latency is reduced, but how well does
it scale, and how does it deal with issues of robustness?

-aaron

Re: Re: >> Apache/Tomcat Collaboration

[cm...@yahoo.com]

On Sun, 30 Sep 2001, Justin Erenkrantz wrote:

> On Mon, Oct 01, 2001 at 01:49:20AM -0700, cmanolache@yahoo.com wrote:
> > I think option 2 ( in-process ) is what mod_jk is doing - the code has
> > been written and used quite a bit in the last year. It didn't got all the
> > attention that Ajp got, because it doesn't work with Apache1.3, only
> > with IIS and NES and Apache2 ( and AolServer ).
>
> I had a feeling you did this with other servers - just not with httpd.
> With Apache 2.0?  Eh, how?  -- justin

Well, I had it working for a while, now it crashes with some VMs.
It's a tricky thing - usually the signals are the biggest problem, java
is very sensitive.

Nothing special - just compile jk with support for jni worker, and
follow the instructions. You may need to set LD_LIBRARY_PATH to
include all the .so from java, and you may have problems with some
VMs - JDK1.2.2 seems the easiest to get working, and surprisingly
1.4 worked also fine ( I'm talking about Linux versions here ).

It's tricky, but I think it's worth it.

Costin

Re: Re: >> Apache/Tomcat Collaboration

[Justin Erenkrantz <je...@ebuilt.com>]

On Mon, Oct 01, 2001 at 01:49:20AM -0700, cmanolache@yahoo.com wrote:
> I think option 2 ( in-process ) is what mod_jk is doing - the code has
> been written and used quite a bit in the last year. It didn't got all the
> attention that Ajp got, because it doesn't work with Apache1.3, only
> with IIS and NES and Apache2 ( and AolServer ).

I had a feeling you did this with other servers - just not with httpd.
With Apache 2.0?  Eh, how?  -- justin

Re: Re: >> Apache/Tomcat Collaboration

[cm...@yahoo.com]

On Sun, 30 Sep 2001, Justin Erenkrantz wrote:

> On Mon, Oct 01, 2001 at 12:41:10AM -0000, Shailesh S. Gokhale wrote:
> > ***
> > Tomcat can be used as either a stand-alone container (mainly for development and debugging) or as an add-on to an existing web server
> > s are supported). This means that whenever you are deploying Tomcat you will have to decide how to use it and, *** if you select options 2 or 3, you will also need to install a web server adapter ***
> > ***
>
> Option 2 is unrealistic with httpd since you'd have to have share the
> memory/address space with the JVM which is just a generally bad idea.
> In theory, yes, you could do it (no one has written code to do this
> AFAIK).

I think option 2 ( in-process ) is what mod_jk is doing - the code has
been written and used quite a bit in the last year. It didn't got all the
attention that Ajp got, because it doesn't work with Apache1.3, only
with IIS and NES and Apache2 ( and AolServer ).


Costin

Re: Re: >> Apache/Tomcat Collaboration

[Justin Erenkrantz <je...@ebuilt.com>]

On Mon, Oct 01, 2001 at 12:41:10AM -0000, Shailesh S. Gokhale wrote:
> ***
> Tomcat can be used as either a stand-alone container (mainly for development and debugging) or as an add-on to an existing web server
> s are supported). This means that whenever you are deploying Tomcat you will have to decide how to use it and, *** if you select options 2 or 3, you will also need to install a web server adapter ***
> ***

Option 2 is unrealistic with httpd since you'd have to have share the 
memory/address space with the JVM which is just a generally bad idea.
In theory, yes, you could do it (no one has written code to do this
AFAIK).  Option 3 is what should be used with httpd - at least from 
my side of the fence.  -- justin