> 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, Patrick
