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: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
