river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Dennis Reedy <dennis.re...@gmail.com>
Subject Re: [jira] [Commented] (RIVER-435) Proposed Standard for Single-Archive Service Deployment Packaging
Date Sun, 23 Feb 2014 22:09:41 GMT

On Feb 22, 2014, at 1205AM, Peter <jini@zeus.net.au> wrote:
> 
> > > Maven or OSGi can provision for maximum compatibility among services 
> > > and proxy's. 
> > 
> > Maven does absolutely nothing in this regard, and in the case of OSGi, 
> > we are dealing with a completely different class loading animal. 
> > Provisioning systems that either use Maven's dependency resolution 
> > (Aether) to make resolved artifacts loadable as local jars are a 
> > different story. 
> > 
> 
> Ok, sorry, wrong assumption, can you explain a little more about how you're using Maven
with Rio? 
> 

I'm not using Maven per se, I am using Aether (https://eclipse.org/aether/). There are 2 cases
here:

1. When a Cybernode is told to instantiate a service, and that service's classpath is an artifact
URL (artifact:groupId/artifactId/version[/type[/classifier]][;repository[@repositoryId]]),
the artifact is resolved (direct and transitive dependencies) to local jars (jars are downloaded
as needed). This forms that search path for the classloader created to load the service's
implementation class. 

2. When a service's codebase annotation is an artifact URL, an implementation of a RMIClassLoaderSpi
is used to resolve (along with it's dependencies and transitive dependencies) the artifact,
and install jars locally. This step is neat, because you can have secure repositories that
require authentication before you can download jars (the configuration for these sorts of
things are in ~/.m2/settings.xml). All of this happens for downloading, and especially before
class loaders are created and proxy classes loaded. The installed artifact location(s) are
then passed to the default RMIClassLoader provider instance (as file based URLs), where a
class loader is created.

I think this is a win from multiple points of view:

- From a performance point of view, instead of accessing classes remotely (using http(s)),
you load them from the file system. Additionally, if you buy off on version management conventions
(where versions are immutable), once you have downloaded jars, you never have to download
them again. So you pay the price once, not every time you have to load a service's codebase.


- You get rid of the lost codebase issue. Once the jars are installed locally, you have them
even if the repository goes down.

- We trust local code correct? If you can verify the authenticity of the jars before you download
them, verify that the download has not been tampered with, how far does that go to address
trust issues?


HTH

Dennis

> 
> Regards, 
> 
> Peter. 
> 
> > 
> > > 
> > > But because these systems also can use non hirarchical relationships 
> > > among ClassLoaders, they can experience class loading deadlock, when 
> > > complex ClassLoader relationships are employed, which parallel class 
> > > loading in Java 7 tries to address. Unfortunately parallel class 
> > > loading is a naive attempt to solve this problem, causing a memory 
> > > consumption explosion with a map based locking system, hopefully a non 
> > > blocking concurrent class loading system will be implemented in Java 9 
> > > to fix class loading deadlock, once and for all. 
> > > 
> > > Thankfully class loading relationships among service api, services and 
> > > proxy's are simple, a hierarchical parent child relationship suffices. 
> > >  Only complex class relationships cause class loading deadlock. 
> > > 
> > > Regards, 
> > > 
> > > Peter. 
> > > 
> > > ----- Original message ----- 
> > > > 
> > > > [ 
> > > > https://issues.apache.org/jira/browse/RIVER-435?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13908727#comment-13908727

> > > > ] 
> > > > 
> > > > Dennis Reedy commented on RIVER-435: 
> > > > ------------------------------------ 
> > > > 
> > > > I'm not sure what the real consequences are if a classloader that 
> > > > loads service implementation classes and then is a parent to a 
> > > > classloader then then is used to load either a discovered service 
> > > > (or receives a remote object as a parameter) is. 
> > > > 
> > > > There will be another classloader created by underlying RMI 
> > > > infrastructure to load the class (since the service classloader) will

> > > > not have the other service's proxy classes in it's search path). I 
> > > > may be missing something, but what are the issues here? 
> > > > 
> > > > > Proposed Standard for Single-Archive Service Deployment Packaging

> > > > > -----------------------------------------------------------------

> > > > > 
> > > > > Key: RIVER-435 
> > > > > URL: https://issues.apache.org/jira/browse/RIVER-435 
> > > > > Project: River 
> > > > > Issue Type: Improvement 
> > > > > Components: com_sun_jini_start 
> > > > > Reporter: Greg Trasuk 
> > > > > Attachments: SingleArchiveServiceDeployment.docx, 
> > > > > SingleArchiveServiceDeployment.pdf 
> > > > > 
> > > > > 
> > > > > The attached document proposes the layout and general requirements

> > > > > for an archive file to support simplified "drag-and-drop" 
> > > > > deployment for services that adhere to the Service Starter 
> > > > > conventions. 
> > > > 
> > > > 
> > > > 
> > > > -- 
> > > > This message was sent by Atlassian JIRA 
> > > > (v6.1.5#6160) 
> > > 
> >


Mime
View raw message