[Isolate-interest] Isolates in Ant, Tomcat, etc...

Fri, 03 Sep 2004 10:59:15 -0400

Hi Curt,

> I'm curious if there is any contact between the
> JSR-121 expert group and the various high-profile
> Apache projects that could benefit from isolates.

I haven't but I don't get around much. Doug Lea might have by now. And Stephen
Hahn is very aware of isolates too and might have mentioned them, but I 
suspect he's too focused on OS goals. If any of these folks (or other
interested parties) will be in Aarhus, Denmark for JAOO, readers could 
perhaps help me connect with them. I'll also be in Copenhagen the Saturday
afternoon before, too, to have a chat with Jesper Zuchlag. Jesper and I have 
already agreed "the more the merrier" for that technical get together,
so anyone interested should send us mail so we can find each other. In lieu
of a better plan folks could meet us at the airport wherever this flight
comes to: 

   18SEP - SAT
   Maersk Air   flight 114  confirmed  class: W    no seat info.
   depart:   London Gatwick, England (LGW)  930A
   arrive:  Copenhagen, Denmark (CPH)  1220P

I'll also be in London at least part of the day on Thursday the 23rd:

>From Aarhus (AAR) to London Stansted (STN)   (Ryanair)
  Thursday, 23 Sep 04 Flight    FR 713Depart     Aarhus (AAR)      10:50
  Arrive        London Stansted (STN)      11:40

(My mug shot is at http://www.jaoo.dk/speakers/)

I guess while I'm at it I should point out that I'm physically located in SW 
Wake county, North Carolina, a few minutes from Red Hat, IBM, etc, in case any 
interested readers are in this area. (I've been trying to make it to a Triangle
JUG meeting and will try to get there in October)

> An isolate enabled Servlet container would allow
> the hosting of arbitrary JSPs, servlets, and .wars
> much more easily.  The number of commercial web hosts
> for Java technologies is woefully small.  An isolate
> enabled Tomcat would help by reducing admin costs.
> If a web app is sufficiently sandboxed, the amount of
> oversight required by the hosting company can be brought
> to near zero.

Isolating virtual domains within a Tomcat environment has been 
discussed as a potentially (very) interesting use case. Some research was 
done that restructured Tomcat's servlet engine into a set of 
isolates, but the aim of that was to confirm the correctness of a
resource management API design with respect to derived
resources (i.e. resources defined in terms of other,
typically more primitive resources like memory usage and
cpu usage).

I should note that you and I are not talking about "wrapping servlets" as
much as wrapping the entire container environment hosting the servlets
for a given {user,domain,etc}. The object visibility models of most of the
*lets don't support simple encapsulation within isolates because they 
depend on visibility of objects outside the classloader scope defining them.
In other words, we're enabling the future to be so bright we have to wear
shades, not threatening familiar legacy Java mechanisms with any big 
disruption of usage patterns. At least that's been our plan all along.

> Meanwhile java.net doesn't host any automated build
> solutions.  Without isolates they would have to provide
> some sort of OS-level sandboxing for any build tools
> they chose to support.  With isolates, they could just
> rely on an isolate enabled version of Ant or Maven.

Here things may be more difficult. Quoting from some of Doug Lea's wording in
the public review specification:

"The Isolate API is intended to be implementable in at least three very 
different styles:

   1. All-in-one. A JVM is constructed within a single operating system 
     (or hardware-level) process but implements isolation guarantees 
      directly in the JVM.
   2. One-to-One. A JVM manages a set of OS-level processes, one per isolate.
   3. Clustered. Isolates may reside on different physical machines within 
      a cluster that provides a consistent view on the external environment 
      for all isolates. (For example, all isolates see the same file system, 
      access the same network services, use the same network addresses, etc.)"

(As careful readers of this list know, SAP has defined a 4th potential style of
implementation with a few details at http://www.bitser.net/i/papers/PAVM.pdf )

So while it's possible for a Java vendor to provide an isolate implementation 
that offers per-user contexts for some aggregate of isolates (a collection 
sharing a common ancestor), this is beyond the scope of the current 
specification and what we intend to deliver as version 1: it will only offer
the shift in context from parent to child isolate afforded by familiar Java 
system properties. We're going carefully control requirements creep, by the
way, for the sake of getting something out rather than talk about it for
another year, but we absolutely should discuss to total agenda for Java 
isolation and just expect some of it to naturally be in the futures domain.

On the other hand it might still be straight forward to provide some
per-user context within a single aggregate with only properties being
mutable, as I know there are some extremely clever Java programmers out 
and about!

> The list goes on and on.

Yes it does. I expect to be sharing a whole other collection of potential
use cases on this list pretty soon. But everything is happening at once now, 
so as always I appreciate your patience. 

> 
> I would like to ask when we will get to play with
> all the cool toys that isolates will enable.
> Since I don't have any reasonable expectation of an
> answer to that question, I'm just hoping out loud
> that the various toymakers are working together.

Your skepticism is not surprising. But cross your fingers (or swing 
a cat over your head) as I'm still optimistic we might be able to do 
something cool and this list will be the first to hear about anything
worth sharing.

Other news is that updated javadoc for the current API design is in the
works and at least the base one or two packages should be in good enough
shape to share, starting around a week from now. 

This javadoc will be in a special package to make it clear that it's tenative
and "experimental", although that said, it will be in tight agreement with the 
dictates of the September 10, 2003 expert group meeting and the javadoc will
show that endorsement.

There will be a few spec bug fixes and oversight corrections but the EG is
being kept up to date and I'm hoping the deltas from the "skeleton" described at
http://altair.cs.oswego.edu/pipermail/isolate-interest/2004-June/000146.html
will be trivial. Actually, as the original 121 EG has discussed just about every
imaginable subject half to death already, it's hard to imagine a change that
can surprise them completely!

And I'm doing (fill in your favorite term here) a three in one thing with this,
updating the spec and making a very simple implementation and test collection 
all at the same time.

Doug Lea's spec-polishing (OK, fixing and polishing) and help from others will 
hopefully make this go a little faster than usual. But you know how it is with 
accretion of responsibilities when you've been someplace for a while, so each 
day is shorter than I need for it to be. :-)

Best wishes,
Pete Soper

-----------------------------
Isolate-interest mailing list
Isolate-interest@altair.cs.oswego.edu
http://altair.cs.oswego.edu/mailman/listinfo/isolate-interest