[kepler-dev] ksw builds

[Kevin Ruland]

Chad Berkley wrote:

>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.
>
>  
>

There is no easy way.  And since Kepler ( even without pt ) is so vast
it will be hard to say definitively if an incompatiblility is
introduced.  That is, unless we spend some very productive time to
define & document the Kepler actor api.  In addition, the 3rd party jars
used by Kepler and to be delivered as part of Kepler needs to be well
established in order for the actor contributors to not introduce many
more redundant (and perhaps conflicting) libraries.

>>- 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.
>
>  
>
I believe that should be considered an interim solution and actually
should not be persued.  The extraction of classes & jars into the
classpath is actually a problem for reasons which might not have been
too clear below.  Basically, there is nothing which prevents kar files
from containing duplicated fq class names which are conflicting.  That
is the two actors cannot be installed simultaneously.  One simple
example of this is one which uses axis 1.1 and another which uses axis
1.2.  This example is very likely since axis 1.1 is required to be used
with globus (hence ecogrid) but it is more desireable and natural for a
developer to choose the latest released version of a jar to code with
(actually axis 1.2.1, and axis 2.0 is in beta...)  Axis 1.1 generated
stubs are incompatible with the axis 1.2 run time - and the other way
around in reverse.  My opinion is the multiple classloader solution
should be persued before implementing a strategy to remove the extracted
classes.  The reason is simple, using a classloader solution does not
require this removal strategy.

>>- 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.
>
>  
>
It actually is possible provided the use of reflection within kar files
is limited to reflecting to classes within the kar itself, or to classes
provided by kepler (and its blessed 3rd party jars).  The way to make it
work is to have a single class instance bridge between the two class
loaders.  The natural choice for this class is the
Actor/Director/Principal-entry-point for the kar.  This would be the
class which the lsid actually refers to.  This class will be the first
class loaded with the kar-specific classloader instance.

>>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.
>
>  
>
Right, the copying itself is time consuming.  However, this time does
not need to be expended at all when using a custom class loader.  The
custom classloaders only need to fetch the toc from all kar file (and
it's included jars) which is not very time consuming.  What I'm really
saying is, using a custom classloader will not be appreciably slower
than the current startup after caching.

>>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.
>
>  
>
Yes, it's complicated even in the simple scenarios.  And of course, I
cannot begin to admit completely understanding all the issues.  However,
since Kepler has control over kar generation, some of the bookkeeping
overhead can be moved from application startup to kar creation.  This
would most likely be acceptable.

Kevin