river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mark Brouwer <mark.brou...@cheiron.org>
Subject Re: [jira] Updated: (RIVER-24) PreferredListGen can create illegal PREFERRED.LIST
Date Tue, 24 Jul 2007 20:25:46 GMT
Hi Gregg,

Gregg Wonderly wrote:
> Mark Brouwer wrote:
>> It seems you want to prevent from downloading JAR files that is driven
>> by the codebase annotation (the codebase annotation contains the encoded
>> PREFERRED.LIST [1]). I believe you want to prevent from downloading JAR
>> files due to limited bandwidth you have over WAN connections.
> 
> I want to have 100 services visible to a client, and discovery to not 
> cause any codebase references and thus force downloading because of 
> PREFERRED.LIST inquiries.

I understand the requirement of minimizing JAR file downloading,
although I take the following measurements to accomplish that:

1) partitioning of download JAR files, the codebase annotation points
    to a dl.jar that is created by Seven while installing services and
    thas uses JarWrapper and that only contains an INDEX.LIST,
    MANIFEST.MF and PREFERRED.LIST. The size is around 1 KBytes and
    refers to a lot of small download JAR files that can efficiently be
    downloaded through the usage of INDEX.LIST. ServiceUI attributes
    have their own download JAR files so these are not downloaded when
    no ServiceUI needs to be instantiated;

2) Seven (upcoming) utilizes a persistent JAR file cache (through a
    custom jar: protocol handler) that will check through an
    if-modified-since whether download JAR files have been updated.
    If not modified or no connection can be established once downloaded
    JAR files are accessible by the class loaders. This is also extremely
    important if you have data that relies on the availability of
    codebases.

The above gave a dramatic reduction in download JAR traffic and a huge
saving in boot times for services that have been seen once by the JVM. I
realize that this requires a lot of plumbing, but I just want to
demonstrate that a lot of what you try to prevent can also be prevented
without any changes to codebases as is.

> You have to consider that I also have my reef project changes to Reggie 
> active too.  Thus, I can select when the service or any Entry values are 
> deserialized.
> 
> My service registrations include Entry values such as service names, 
> icons, javax.help files (referenced by URLs) etc.  I want to be able to 
> display to the user, icons for all visible services without 
> unmarshalling anything except the bare minimum which is needed to show 
> the user icons and names.

I believe with a proper partitioning of your download JAR files you can
get very far. I'm not saying that this is an easy task though. There is
no way to prevent your service proxy to be unmarshalled and these can be
rather large. There are tricks possible there (lazy instantiation of
working parts through reflection) but this can get ugly.

>> To me it looks like you want the client to be the discriminator whether
>> classes (and thus the download JAR file) should be downloaded and not
>> the server through the PREFERRED.LIST it provides in the codebase
>> annotation, why do you want to turn that around?
> 
> I have a known platform that my services adhere to.  That platform is 
> expressed in the PREFERRED.LIST explicitly, but is also expressed in the 

I think I don't understand what you mean with the platform being
expressed in the preferred list as there is no notion of platform in the
semantics for preferred list.

I realize that some services assume a certain platfom to be available to
be able to work (their minimum platform) and that might differ from e.g.
the JTSK Platform. That is fine, but I always though of using an Entry
for that purposes, an entry that would be part of the minimum Jini
Platform on top of which another Platform could be defined, so the Entry
could be recognized by each and every Platform.

I haven't given it much though but it seems codebase or preferred list
feels the wrong place for specifying a platform. Codebase indicates
where the class definition(s) for some marshalled object can be obtained
and preferred list how class delegation should take place. A Platform
means to me the assumptions made by the service for it to be usable by a
client. When it doesn't meet the minimum platform it will likely fail
for some of its operations.

> jar content and the classloader behavior implicitly.  I want the 
> platform that the service is asserting to be conveyed to the client as 
> part of the service registration, not as part of the services codebase 

You really try to prevent from any form of downloading :-) and I'm
afraid that if we are going to allow meta-data in the codebase we get on
a slippery slope (I still see problems with the increase of data due to
all those 'larger' annotations).

> content.  This would allow the client to decide whether or not it could 
> be compatible with that platform, early on.

I think a Platform Entry together with proper partitioning of download
JAR files can get you very far, but I realize that unmarshalling the
service proxy is still problamatic. If a combination of proper
partitioning and maybe some enhancements to ServiceRegistrar we might
get even further.

>> [1] I guess the codebase annotation is getting rather large that way
>> (although RFC 2616 doesn't seem to place any a priori limit on the
>> length of a URI you might run into problems in reality due to this) and
>> I think the various marshalled streams don't optimize on recurring URIs
>> (no URI table I can detect for classes with the same annotation) so you
>> will be consuming additional bandwidth (a lot?).
> 
> What I would say is that it's not part of the URL, but rather part of 
> the structure of the annotation string, which would break compatiblity 
> with arbitrary RMI applications when using the JRMP exporter.  I.e. you 

I think we should stick with URL/URI for codebase annotation, but I
think that still leaves some room for encoding meta-data if we come up
with useful meta-data.

> This, is just my initial thought of a trivial to implement solution for 
> getting the information into the codebase string.  It might be more 
> compatible to use
> 
>         return codebase+" pref:/"+URLCoder.encode( new String(data) );
> 
> to make the additional information be recognizable for what it is.
> 
> The PreferredClassLoader would be changed to look at the annotation for 
> the defined separator ('\n' or " pref:/" or whatever) and use that 
> PREFERRED.LIST content instead of downloading one or more jars and 
> extracting it.

What if we come up with a scheme that allows for encoding of meta-data
that when not understood can be ignored and works as normal (downloading
of JAR file(s) to obtain meta-data) but can be utilized by those who
want to do that for whatever purpose.

Also what I don't understand at this moment is why a platform identifier
is not sufficient, why do you want to communicate the whole preferred
list. If you know the platform there are hooks to customize your
delegation model (in Seven I do the same thing, there is a platform
definition that controls the exact delegation model, so service can't
hike upon some implementation details). In such a case if a class is not
part of the platform it needs to be downloaded at which point you can
trigger the initial download of the JAR file that contains the
PREFERRED.LIST.

Just some thought because I really can't oversee all the implications.
-- 
Mark



Mime
View raw message