river-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Patrick Wright <pdoubl...@gmail.com>
Subject Re: Maven repository Entry was Re: Codebase service?
Date Wed, 26 May 2010 13:17:26 GMT
> So what's the downside of dynamic download, specifically?  I can see the
> issue in a bandwidth limited situation (which is actually not Jini's
> original target, but could probably be handled with sufficiently bright
> jar caching), but in a well-connected local area network environment
> (Jini's design center) what problems do we face, and might there be
> simpler ways to handle them?

Hi Greg

I'll just give my perspective. In our environment we control both the
client and service-side updates and deployments, and we never have a
need for dynamic changes to proxy classes or anything related to the
-dl.jar files. This has two implications: we're performing a download
for all -dl.jar files from all services each time we restart our
clients, and we have a weak spot in our system related to codebase
availability. On each restart, our clients pretend they don't know the
classes from the services, even though in our deployment process they
obviously have a right to--and on top of that that the -dl.jars are
static following a deployment--and this means there is this extra
lookup effort which all has to work perfectly, each and every time. It
just doesn't make sense; we ourselves don't need this feature of Jini,
by and large, although we appreciate the reasoning behind it.

As an example of where this has bitten us--our admins has set up a new
hosting environment for one of our clients, and forgot that the
client's container was configured to write temp files to a special
directory, and didn't create this directory. The Jini infrastructure
had no place to write the downloadable JAR files. What sort of
information did we have to go on?
- client logs report that the class com.sun.jini.blah can't be found, wtf?
- service codebase logs report broken pipe from connection from ip xyz
port (randomly-assigned port number)
- all other clients are able to see and interact with this service
- end users of the application aren't able to use the application
because a critical service is unavailable

We've had similar "unavailable codebase" problems cropping up due to
any number of configuration issues over the years. In each and every
case, it's completely mysterious to almost all of us that codebase
might even be an issue, it's also mysterious how to track down the
specific problem and fix it (the reporting by and large is so deep in
the Jini infrastructure that logging rarely helps), and, worst of all,
this is arising from a feature that we don't even care to use.

I'll just add to that that after 3 or more years of using Jini as the
backbone of our synchronous communication, we've had a hard time
growing the number of people who have more than passing knowledge of
it, making problem resolution more difficult.

Hence, for people in our situation, I'd like there to be a drop-dead
simple alternative to dynamic code loading, and where the dynamic code
loading was an interesting option, but not a requirement. I do look
forward to the day when I find a real need for it, though, because I
think it's a rocking good idea (really).

My perspective,

View raw message