www-community mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Steve Brewin" <sbre...@synsys.com>
Subject RE: WORA Considered Evil ;-)
Date Fri, 27 Jun 2003 18:07:52 GMT
Rather than picking off Piers points one by one I'ld say that the "rock
solid arguments *not* to use JAMES as a MTA" do not hold in a Java
environment and therefore do not apply to James.

Pier trusts the setup he describes because it solves the problems
encountered in a C on Unix world. These are not the same problems
encountered by James, or any other Java application running on a JVM with an
appropriate security policy, whatever the OS.

There is no need to distibute James' components over multiple JVMs to
enhance security or robustness.

Security isn't an issue in the same way as it is with C. With C I can
happily play around with any memory location in my address space but the JVM
ensures that objects are bound to and do not break their contracts. A
greater level of isolation is provided within a JVM than is provided by
running separate processes in Unix.

A thread going down within the JVM does not take the JVM down with it unless
an unhandled Error or Exception is thrown. If the Error/Exception handling
is correct, the JVM will only terminate when there is no point in
continuing, generally due to misconfiguration or resource depletion. These
are issues that would have the same consequence in a multiple JVM, same
machine environment.

Using multiple VMs forces the use of some kind of remote interface. The poor
performance of remote interfaces is well known and contributed much to the
poor performance of EJBs until local interfaces were introduced. This is not
a road down which to travel without serious cause.

In the early days of Java there was a good reason to run multiple JVMs.
Performance when garbage collecting large heaps was very poor. Having
several smaller heaps by way of multiple JVMs was a workaround. Current JVMs
are much much better, so its no longer a good trade off against the cost of
remote interfaces.

These days, the only reason for multiple JVMs is to distribute across
multiple machines for scalability and robustness (if a machine goes down or
runs out of resources, the app. continues to run on the others).

And finally, as a general observation. Modern JVMs make extremely good use
of the native threading libraries at their disposal. They can be configured
to exploit them as required, look at Sun's latest for instance. And if you
want JVM fast start (pre-loaded, ready to go JVMs) its on its way.

-- Steve

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

View raw message