Gregg Wonderly wrote:
Mark Brouwer wrote:
Gregg Wonderly wrote:
I think that the behavior of fallback URLs is useful. Given the
framework that
exists, I think that the current implementation is applicable. But,
I also
I've a bit of a problem positioning your language Gregg due to the words
fallback and framework, but are you suggesting the new behavior should
be conditionally. Note that as far as I can tell the only
de-optimization is the one Peter will be remembered for the rest of his
life.
Let me try with different words...
Ok I understand where you want to go to, however there was a thread
during the Davis project which I'm unfortunately can't refer to as the
archives have been closed, where I also referred to the current
semantics for having the requirement of PREFERRED.LIST in the first JAR
file. I attached my post and the responses of Peter and Laird Dornin for
completeness.
There is an issue in the Sun bug database
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4302427 that suggest
that the fallback behavior you are referring to in itself is a bug.
Based on the current semantics of PreferredClassLoader the proposed
change doesn't alter its behavior.
If there are multiple URLs in the codebase, and two or more actually
points at the same content, then one of those URLs can be considered
"fallback" URLs. I.e. if one URL is not accessible, the client will
hopefully be able to load code from another. Thus, the failure handling
associated with "JAR not accessible" as opposed to "PREFERRED.LIST" not
present is important. Also, the location that the PREFERRED.LIST comes
from is important.
You are familiar with XML based configuration. Imagine that you could
Is that a complement Gregg ;-) I think we should start a separate thread
on improvements of codebase annotation for it seems you just want to
have a complete new protocol handler Gregg that solves many issues
around mobile code, but I think I leave it up to others who have done
their fair share of research/thinking to comment on this first.
--
Mark
--- Begin Message ---
Return-path: <[EMAIL PROTECTED]>
Received: from pavo.virgil.nl (pavo.virgil.nl [194.134.241.138])
by virgo.virgil.nl (iPlanet Messaging Server 5.2 (built Feb 21 2002))
with ESMTP id <[EMAIL PROTECTED]> for [EMAIL PROTECTED]
(ORCPT [EMAIL PROTECTED]); Thu, 31 Oct 2002 15:14:24 +0100 (CET)
Received: from jini.org (h36.sfo.collab.net [64.125.133.46])
by pavo.virgil.nl (8.10.2+Sun/8.10.2) with SMTP id g9VEENV00943 for
<[EMAIL PROTECTED]>; Thu, 31 Oct 2002 15:14:23 +0100 (CET)
Received: (qmail 4374 invoked by uid 5302); Thu, 31 Oct 2002 14:14:17 +0000
Received: (qmail 4365 invoked from network); Thu, 31 Oct 2002 14:14:16 +0000
Date: Thu, 31 Oct 2002 15:14:16 +0100
From: Mark Brouwer <[EMAIL PROTECTED]>
Subject: Codebase redundancy and PREFERRED.LIST
To: Davis <[EMAIL PROTECTED]>
Reply-to: [EMAIL PROTECTED]
Message-id: <[EMAIL PROTECTED]>
Organization: Virgil B.V.
MIME-version: 1.0
X-Mailer: Mozilla 4.78 [en] (WinNT; U)
Content-type: text/plain; charset=us-ascii
Content-transfer-encoding: 7BIT
X-Accept-Language: en
Precedence: bulk
Delivered-to: mailing list [EMAIL PROTECTED]
Mailing-List: contact [EMAIL PROTECTED]; run by ezmlm
List-Post: <mailto:[EMAIL PROTECTED]>
List-Unsubscribe: <mailto:[EMAIL PROTECTED]>
List-Help: <mailto:[EMAIL PROTECTED]>
X-No-Archive: yes
While thinking about codebase redundancy and preferred classes I started
to wonder a) how (Preferred) classloaders in general work with
unreachable URLs and b) what the effect of a broken link can be on
retrieving the PREFERRED.LIST
Assume my classes are marshalled with a codebase annotation of:
'http://host-A/dl.jar http://host-B/dl.jar'
The 2 jar files are identical, the only difference is that they are
served from 2 different hosts. The 2 jar files may refer to other jar
files via the Class-Path manifest entry.
A client classloader involved in unmarshal the annotated classes will
probably try to obtain the dl.jar from host-A. If that doesn't succeed
(broken network, webserver down for maintenance, etc.) what will the
PreferredClassLoader do, will it ignore http://host-A/dl.jar and just
use http://host-B/dl.jar ?
If so will it use the PREFERRED.LIST of the dl.jar from host-B. Stated
in the javadoc at PreferredClassLoader is: "These preferred lists must
reside in a JAR file or directory which is relative to the first URL of
each preferred class loader and must be named by the value of the static
field PreferredClassProvider.PREF_NAME". In my opinion
http://host-B/dl.jar is the second URL.
What if after a while (in a situation not all jar files from host-B are
fetched and cached) host-B goes down and host-A is up and running again?
BTW something that keeps popping up in my mind at regular intervals: I
remember from previous discussion at the RMI list and Jini Users that
the URLClassLoader (or http protocol handler) always caches jar files
once retrieved and doesn't check if it has been modified. If this is
still true are there any plans to change this behavior. Probably I
oversee many issues involved with versioning but I think this would be
the first hurdle to take. Probably using a different URL for each
version is a better and easier approach as this would allow different
versions to coexists. We have a need to upgrade services in a running
system, my guess is that these upgrades in 95% of the cases are
implementation (preferred classes) related and not specification,
therefore I'm thinking about a right approach.
--
Mark Brouwer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
>From - Wed
--- End Message ---
--- Begin Message ---
>While thinking about codebase redundancy and preferred classes I started
>to wonder a) how (Preferred) classloaders in general work with
>unreachable URLs and b) what the effect of a broken link can be on
>retrieving the PREFERRED.LIST
>
>Assume my classes are marshalled with a codebase annotation of:
>
> 'http://host-A/dl.jar http://host-B/dl.jar'
>
>The 2 jar files are identical, the only difference is that they are
>served from 2 different hosts. The 2 jar files may refer to other jar
>files via the Class-Path manifest entry.
>
>A client classloader involved in unmarshal the annotated classes will
>probably try to obtain the dl.jar from host-A. If that doesn't succeed
>(broken network, webserver down for maintenance, etc.) what will the
>PreferredClassLoader do, will it ignore http://host-A/dl.jar and just
>use http://host-B/dl.jar ?
>
>If so will it use the PREFERRED.LIST of the dl.jar from host-B. Stated
>in the javadoc at PreferredClassLoader is: "These preferred lists must
>reside in a JAR file or directory which is relative to the first URL of
>each preferred class loader and must be named by the value of the static
>field PreferredClassProvider.PREF_NAME". In my opinion
>http://host-B/dl.jar is the second URL.
That opinion/interpretation is correct. More text from the current
spec:
If there is no resource in the location described by
PreferredClassProvider.PREF_NAME, preferred class loaders
should assume that they contain no preferred resources. At
runtime, any preferred list file resource that is located
relative to the first URL of a preferred class loader will
provide the only source of preferred information for the
loader's entire path of URLs (preferred lists in other
locations are ignored)
Whether or not the current spec makes this entirely clear, the idea is
that if a PreferredClassLoader cannot determine with reasonable
certainty that the contents of the first URL either does or does not
contain a PREFERRED.LIST, then the class or resource loading operation
should fail (with a ClassNotFoundException or null, the latter case for
resource-loading being somewhat ambiguous, unfortunately).
In other words, PreferredClassLoader.isPreferredResource must throw an
IOException (rather than returning false) if it cannot determine the
existence of a PREFERRED.LIST at the first URL definitively one way or
the other (such as because of a network failure). The current "@throws
IOException" specification of isPreferredResource is not well worded to
reflect this intention, but that's a known issue that will be fixed.
>BTW something that keeps popping up in my mind at regular intervals: I
>remember from previous discussion at the RMI list and Jini Users that
>the URLClassLoader (or http protocol handler) always caches jar files
>once retrieved and doesn't check if it has been modified.
Specifically, it's the "jar:" URL scheme handler [that is responsible
for this caching], which is used by the URLClassLoader implementation
to load classes and resources from URLs to JAR files-- and
URLClassLoader doesn't provide a way to control what value of
"useCaches" to use for the "jar:" URLs it uses internally.
>If this is still true are there any plans to change this behavior.
Not that I know of. Workarounds still include the
URLConnection.setDefaultUseCaches(false) hack and providing your own
"jar:" URL scheme handler, as discussed in these messages:
http://archives.java.sun.com/cgi-bin/wa?A2=ind0202&L=jini-users&P=R24352
http://archives.java.sun.com/cgi-bin/wa?A2=ind0206&L=jini-users&P=R24578
-- Peter
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
Peter Jones - JavaSoft East wrote:
>
> In other words, PreferredClassLoader.isPreferredResource must throw an
> IOException (rather than returning false) if it cannot determine the
> existence of a PREFERRED.LIST at the first URL definitively one way or
> the other (such as because of a network failure). The current "@throws
> IOException" specification of isPreferredResource is not well worded to
> reflect this intention, but that's a known issue that will be fixed.
>
This rules out the possibility of Codebase Redundancy by specifying
multiple redundant URLs in the codebase. However I see at least two
reasons to have such a feature:
- service is exported on multiple interface. In case the networks
are truly separated and there is just one URL that points to a
webserver in one of the networks, only clients on the network
that can reach the webserver are able to download the classes;
- I have a cluster of services running at distinct locations and the
registered proxies have some failover mechanism. I replicate the
download jar files at multiple locations as I don't want to have
a single point of failure, there must be a way that once annotated
classes get their code from multiple places to make this work;
I could invent my own protocol to accommodate these requirements like
the JRAP project (http://jrap.jini.org/) but then I have the problem of
convincing people to install the protocol handler, we all know what my
chances are to get this done at a large scale.
Therefore it would be nice if such a feature could be arranged by the
codebase annotation and that URLClassLoader and therefore
PreferredClassLoader could deal with this or ... why not make this a
feature* of the httpmd protocol handler we all hope will be common once
on every client JVM. It could be implemented within the already defined
syntax of the httpmd URL if the comma ',' would be defined as a multiple
comment separator, e.g.:
httpmd://host1:port/path/dl.jar;md5=xxx,bu:host2:port,bu:host3:port,.jar
In case a comment starts with 'bu:' it defines an alternative location
for retreiving the download jar. This would require that the path
segment is the same for each download location but this is not a
problem.
[*] I fear the answer will be in terms of "Right now our energy is
focused on getting Davis done" ;-) but whether such a feature is in fact
a requirement for some next release would be nice.
--
Mark Brouwer
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- End Message ---
--- Begin Message ---
On Tuesday 05 November 2002 11:11 am, Mark Brouwer wrote:
> This rules out the possibility of Codebase Redundancy by specifying
> multiple redundant URLs in the codebase.
Yes, it does. However, there are good reasons to believe that the fail over
behavior of URLClassLoader is itself a bug. For more information see:
http://developer.java.sun.com/developer/bugParade/bugs/4302427.html
> However I see at least two reasons to have such a feature:
>
> - service is exported on multiple interface. In case the networks
> are truly separated and there is just one URL that points to a
> webserver in one of the networks, only clients on the network
> that can reach the webserver are able to download the classes;
>
> - I have a cluster of services running at distinct locations and the
> registered proxies have some failover mechanism. I replicate the
> download jar files at multiple locations as I don't want to have
> a single point of failure, there must be a way that once annotated
> classes get their code from multiple places to make this work;
>
> I could invent my own protocol to accommodate these requirements like
> the JRAP project (http://jrap.jini.org/) but then I have the problem of
> convincing people to install the protocol handler, we all know what my
> chances are to get this done at a large scale.
Yes, since JRAP URLs are ip address / host name independent, you can use them
to serve classes to clients on both sides of a network interface. But the
deployment problem certainly does get in the way. JRAP alleviates this
problem somewhat by introducing a way to download custom algorithms for
handling code... so at least with JRAP you only need to install one protocol
handler in every client. Thereafter customizeable algorithms (for fault
tolerance, etc.) can be installed dynamically.
> Therefore it would be nice if such a feature could be arranged by the
> codebase annotation and that URLClassLoader and therefore
> PreferredClassLoader could deal with this or ... why not make this a
> feature* of the httpmd protocol handler we all hope will be common once
> on every client JVM. It could be implemented within the already defined
> syntax of the httpmd URL if the comma ',' would be defined as a multiple
> comment separator, e.g.:
I think its quite hard to know in advance what code downloading robustness
strategies an application will want to emply ahead of time. Trying to add
behavior that works for everyone would add a large amount of complexity to
the currently simple httpmd url protocol handler. I think URLClassLoader has
introduced a false sense of robustness with its glib fail over mechanism.
> httpmd://host1:port/path/dl.jar;md5=xxx,bu:host2:port,bu:host3:port,.jar
>
> In case a comment starts with 'bu:' it defines an alternative location
> for retreiving the download jar. This would require that the path
> segment is the same for each download location but this is not a
> problem.
Feels very much like a specific solution in very general code.
> [*] I fear the answer will be in terms of "Right now our energy is
> focused on getting Davis done" ;-) but whether such a feature is in fact
> a requirement for some next release would be nice.
Its interesting to note that the Sun folks once considered a notion of
"dynamic protocol handlers." The JRAP project at least in part tries to
provide that capability.
--Laird
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
--- End Message ---
