[kepler-dev] ksw builds

[Chad Berkley]

Hi Kevin,

Sorry again for my late reply but here goes.  Note that I'm now calling
the ksw files "kar" files now.  If you have any questions why, ask
bertram :)

Kevin Ruland wrote:
> Chad,
> 
> I had some time to think about the ksw loading system and have some
> suggestions.  First there are some big issues which must be considered
> using the current strategy.
> 
> - There is the possibility that in the future the ksw binary api might
> change.  By this, I mean the .class files included in a specific ksw
> file cannot work with a newer install of Kepler.  Given that Kepler is
> so huge and has many dependencies on external jars and internal APIs
> (ptolemy, and other kepler internal subsystems), the likelyhood of such
> problems is pretty large.

This is definitely an issue.  PTII contains a parameter called
"requiredVersion" that you can insert into a workflow.  This tells the
system that a specific version of PTII is required for the workflow.  We
could probably work a similar system using the lsids embedded in the kar
files.  We've thought about versioning a lot and unfortunately, there
are no easy solutions to it.

> 
> - A given ksw should be able to be uninstalled easily.  I think easily
> would be just as simple as the install process (which is "copy ksw to
> specific directory") so it should be "remove ksw from directory and
> restart kepler".

Yeah, this can probably be worked out.  the system should be able to
notice that a kar file is no longer present in the kar directory and go
remove all of the extracted items and ids.

> 
> - There is the possibility that even though two ksw's are both binary
> compatible with a given version of Kepler, they might be incompatible
> because of conflicting classes and packages.  The ksw structure is
> designed to contain multiple jar files.  It is possible that two
> different ksw's might be dependent on different versions of conflicting
> jar files.

We've been planning to have dynamic class loading for a while.  That's
one of the next things I plan to start playing with.  Basically, the
class loader should note classes that have the same name but different
lsids and be able to dynamically load/unload them when they need to be
used.  This is not going to be easy.  It might even be impossible :).
I'm planning to start messing with it soon though.

> 
> The current strategy of blowing apart the classes into a directory on
> the appliciation classpath pretty much fails all these reguards.  The
> uninstall process is very difficult and non-intuitive.  It requires the
> user to blow away the cached classes as well as remove the ksw file. 
> There is no control over naming conflicts.  And further having these
> classes in the classpath can result in wacky errors from the jvm -
> perhaps even segfaults - when trying to load binary incompatible classes.
> 
> I suggest you revise the strategy by incorporating mutliple class
> loaders and a custom class loader for the entire application and impose
> some additional structure on the ksw file.  I believe a ksw file is to
> have a single actor/director as its main entry point.  When the system
> starts up, it needs to spin through the ksw files and register the entry
> point class under a specific logical class name which is generated at
> run time from the ksw filename + directory.  A custom per-ksw class
> loader would then be instantiated and the ksw entry point loaded with
> that class loader.
> 
> Now whenever a class is requested by the main actor in a ksw, it will
> request the class from the per-ksw class loader.  The per-ksw class
> loader will first check the jar files in the ksw file for the class, if
> it's found, it will load it.  If it doesn't find it, it will pass the
> request back to the application's class loader which will do the normal
> resolution process.
> 
> You might argue that this will result in significant time during class
> loading given your experience with Kepler startup using the current
> strategy.  However, I believe (cannot prove as yet) the delay you
> experience is due to the file copies done using the read-write loop in
> the KSW loader.  Doing file copies in java this way is very time
> consuming.  If you think about what Java currently does to load classes
> from jar files, not much overhead is added.  In addition, this overhead
> would only be done if the specific actor is being used in the workflow.

Most of the startup delay right now is because of the way the annotation
system is rebuilding the actor library.  Once the kar files are exploded
and their contents cached, no files are getting copied at all.  The CRC
checksum is getting generated and checked, but I don't think that's
causing too much of a delay.  Shawn and I are going to redo the
annotation system so hopefully we'll get rid of a lot of that delay when
we do.

> 
> Using custom class loader hierarchy is nothing new.  The ear file
> specification does just this same trick to allow deployment of multiple
> ejb-jar & war files.  Here's an article on TheServerSide which describes
> the process
> http://www.theserverside.com/articles/article.tss?l=ClassLoading and one
> OnJava http://www.onjava.com/pub/a/onjava/2001/07/25/ejb.html
> 
> This should give you the general idea.
> 
> In order to address the binary compatibiltiy issue, I suggest adding a
> custom attribute to the Manifest file which marks the KSW as generated
> by a specific release of Kepler or alternatively by a release of the
> Kepler binary api -- whatever that may be.  When trying to load ksw's
> first the mainfest would be checked for this information and compared to
> the internal release number if they are compatible, then all is well and
> the ksw is loaded, otherwise issue error message and ignore the ksw.
>

A lot of this stuff is going to be changing soon.  I think Dan is also
going to help with the class loading issues.  I think in the next
developer meeting we should probably have at least 1/2 day to talk about
them.  It's pretty complicated.

chad