You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@river.apache.org by Greg Trasuk <tr...@stratuscom.com> on 2011/11/17 04:27:15 UTC

Re: Thinking Aloud - fundamental challenges of jvm based distributed computing

On Wed, 2011-11-16 at 21:48, Peter Firmstone wrote:

> +1 for Greg's new container too.   I've briefly looked at the code and 
> will have some time soon to study it more in depth.  Greg, is it 
> possible to integrate security and configuration as well?  Is some of 
> the stuff from Tim Blackman's Jini in a jar of use?

The container is designed for:
- pluggable deployers.  One for 'ServiceStarter' services, one for
surrogates, perhaps one for an annotation-based service API, etc.  In
fact it's a great platform for experimentation, as we can easily create
deployers to test out various service-creation API approaches.  No need
to standardize on any particular one.
- pluggable configuration.  There is a 'core configuration'in an xml
file in the bootstrap classpath that further loads other configuration. 
Right now, that 'further configuration' is another xml file in the file
system, but there's no reason that yet further configuration couldn't be
pulled from a remote configuration service.  So far I'm just solving the
immediate problem, but trying not to rule out possibilities.
- pluggable security definition.  It'll be easier to explain when I'm
just a little further on in the implementation.
- It's actually built on a dependency-injection framework that is sort
of a minimalist version of Spring or Google Guice.  In retrospect I
probably could have used an existing framework, but was having a good
time learning about annotations.

I haven't looked at "Jini in a jar". 

I'm pretty close to being able to host "ServiceStarter" services inside
the container, such that the container hosts its own infrastructure
(reggie, mahalo, outrigger, etc).  Next step will be to make the
security infrastructure work, then setup monitoring of a deployment
directory such that applications can be dynamically deployed/undeployed
(a-la Tomcat or JBoss) by copying them into the deployment directory.

I'll keep you posted...

Greg.



Re: Thinking Aloud - fundamental challenges of jvm based distributed computing

Posted by Peter <ji...@zeus.net.au>.
See inline:
----- Original message -----
>
> On Wed, 2011-11-16 at 21:48, Peter Firmstone wrote:
>
> > +1 for Greg's new container too.    I've briefly looked at the code and
> > will have some time soon to study it more in depth.  Greg, is it
> > possible to integrate security and configuration as well?  Is some of
> > the stuff from Tim Blackman's Jini in a jar of use?
>
> The container is designed for:
> - pluggable deployers.  One for 'ServiceStarter' services, one for
> surrogates, perhaps one for an annotation-based service API, etc.  In
> fact it's a great platform for experimentation, as we can easily create
> deployers to test out various service-creation API approaches.  No need
> to standardize on any particular one.
> - pluggable configuration.  There is a 'core configuration'in an xml
> file in the bootstrap classpath that further loads other configuration.
> Right now, that 'further configuration' is another xml file in the file
> system, but there's no reason that yet further configuration couldn't be
> pulled from a remote configuration service.  So far I'm just solving the
> immediate problem, but trying not to rule out possibilities.
> - pluggable security definition.  It'll be easier to explain when I'm
> just a little further on in the implementation.
> - It's actually built on a dependency-injection framework that is sort
> of a minimalist version of Spring or Google Guice.  In retrospect I
> probably could have used an existing framework, but was having a good
> time learning about annotations.

Are you using the jsr 330 API annotations?  Recent versions of Guice and spring support it, it's a very minimal api.

>
> I haven't looked at "Jini in a jar".

Well worth a look, it allows a user to run a Jini application simply by downloading and running a jar file, it contains the platform, configuration and security config including a key server and has a sysres url scheme to locate resources.

Tim donated it to River last year.

Cheers,

Peter.

>
> I'm pretty close to being able to host "ServiceStarter" services inside
> the container, such that the container hosts its own infrastructure
> (reggie, mahalo, outrigger, etc).  Next step will be to make the
> security infrastructure work, then setup monitoring of a deployment
> directory such that applications can be dynamically deployed/undeployed
> (a-la Tomcat or JBoss) by copying them into the deployment directory.
>
> I'll keep you posted...
>
> Greg.
>
>


Re: Thinking Aloud - fundamental challenges of jvm based distributed computing

Posted by Greg Trasuk <tr...@stratuscom.com>.
Good point, Gregg.  Thanks for the input.  I've noticed the same thing
with some servers.  JBoss seems to do OK with it, so reasonable
behaviour appears possible.  I'll make sure to test for it.

Greg Trasuk

On Thu, 2011-11-17 at 09:10, Gregg Wonderly wrote:
> On 11/16/2011 9:27 PM, Greg Trasuk wrote:
> > I'm pretty close to being able to host "ServiceStarter" services inside the 
> > container, such that the container hosts its own infrastructure (reggie, 
> > mahalo, outrigger, etc). Next step will be to make the security infrastructure 
> > work, then setup monitoring of a deployment directory such that applications 
> > can be dynamically deployed/undeployed (a-la Tomcat or JBoss) by copying them 
> > into the deployment directory. I'll keep you posted... Greg. 
> 
> As you are working on the deployment mechanisms and deployment detection, think 
> about how to keep partial downloads from being loaded and then aborted.  Tomcat, 
> in particular, has a behavior that when I just scp a .war into the WEB-INF tree, 
> if it scans while the copy is in progress, and then starts loading before the 
> copy finishes, two bad things happen; 1) the class loading aborts with an EOF or 
> other error due to the .WAR file not being complete, and 2) Tomcat will ignore 
> the final, complete download if it finishes cleaning up after the download 
> completes.  You then have to either restart tomcat, or try and copy the .WAR 
> again.  The service disappears while you straighten things out.   The update 
> should try and provide an atomic switch between the old version and the new 
> version without any loss of service.
> 
> Gregg


Re: Thinking Aloud - fundamental challenges of jvm based distributed computing

Posted by Gregg Wonderly <gr...@wonderly.org>.
On 11/16/2011 9:27 PM, Greg Trasuk wrote:
> I'm pretty close to being able to host "ServiceStarter" services inside the 
> container, such that the container hosts its own infrastructure (reggie, 
> mahalo, outrigger, etc). Next step will be to make the security infrastructure 
> work, then setup monitoring of a deployment directory such that applications 
> can be dynamically deployed/undeployed (a-la Tomcat or JBoss) by copying them 
> into the deployment directory. I'll keep you posted... Greg. 

As you are working on the deployment mechanisms and deployment detection, think 
about how to keep partial downloads from being loaded and then aborted.  Tomcat, 
in particular, has a behavior that when I just scp a .war into the WEB-INF tree, 
if it scans while the copy is in progress, and then starts loading before the 
copy finishes, two bad things happen; 1) the class loading aborts with an EOF or 
other error due to the .WAR file not being complete, and 2) Tomcat will ignore 
the final, complete download if it finishes cleaning up after the download 
completes.  You then have to either restart tomcat, or try and copy the .WAR 
again.  The service disappears while you straighten things out.   The update 
should try and provide an atomic switch between the old version and the new 
version without any loss of service.

Gregg