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: Change for PreferredClassLoader its way of determining the existence of PREFERRED.LIST ?
Date Wed, 10 Jan 2007 10:20:33 GMT
Hi Dan,

Dan Creswell wrote:
> Hi Mark,
> 
> Not sure I understand exactly where you are going so how about one of my
> patent-pending dumb questions:
> 
> How is this different from me ensuring that each service I deploy has,
> in the same JVM an http server to serve the .jars on it's codebase?

I try to implement reliability features in Seven that work independent
of the way the (external) service used by other services/clients
deployed in Seven are implemented/deployed. Although the speed increase
I experienced with some tests over the Internet made me a very happy
person :-)

Also deploying an internal JAR file server as part of the same JVM as
your service is deployed within has its own drawbacks, as that JAR file
server might have served JAR files that are being used for other
purposes than just remote communication with a service. Bringing your
JVM down will also harm those that have created dependencies on those
JAR files [1], and don't forget about that just wipe JAR files once
served from their file system.

> Essentially, that would mean that if I could reach the service, I could
> get it's .jars.  If I can't do that, I have to go get some other service.

While that is indeed a common approach, sometimes you have a reference
to a service that you can't easily swap for another, e.g. when you are
in the middle of a 2-phase transaction and something happens.

> Does it just come down to .jar caching in clients/other services for
> purposes of speed etc?

Nope, I hoped that was clear from my listing of benefits from this
approach, the posting is mainly with regard to reliability.

But to add some more language, though will keep it short. We all know
that downloadable code is a gift and a curse at the same time. I'm
trying very hard with Seven to solve some of the problems associated
with that by making evolution of services possible over a long time span
for some use cases. Although not everything will be possible due to some
of the problems outlined by Michael Warres' "Class Loading Depression in
Java™ RMI and Jini Network Technology".

But a case I've run into often is that we persisted object in marshalled
form, e.g. an object that represents a specialized proxy to a
transaction service and that we had failures due to codebase unavailability.

Assume the transaction server is down for whatever reason as well as its
codebase server. Upon retrieval of the specialized proxy I will get a
ClassNotFoundException without the cache, and the specialized proxy with
the cache in place assuming a different implementation of
PreferredClassLoader.

The ClassNotFoundException I will likely see as a definite exception and
that means I have a much bigger problem than with a specialized proxy in
my hand that throws a ConnectException [2].

[1] the next feature I'm working on is prefetching of download JAR files
that are listed in the Class-Path entry of the MANIFEST.MF to increase
reliabilty for those JAR files that have not been requested by the class
loader as result of the usage at runtime.

[2] another request to increase reliability in certain scenarios I will
post shortly, as often I've been confronted by a NoSuchObjectException
what many people consider a definite exception for which I would have
liked to throw a different exception under some conditions.
-- 
Mark

Mime
View raw message