JDK-5104552 : need mechanism to associate a timer w/ class loading mechanism during n/w outage
  • Type: Enhancement
  • Component: core-libs
  • Sub-Component: java.net
  • Affected Version: 1.4.2_05
  • Priority: P3
  • Status: Closed
  • Resolution: Not an Issue
  • OS: windows_2000
  • CPU: x86
  • Submitted: 2004-09-20
  • Updated: 2006-12-08
  • Resolved: 2006-12-08
Related Reports
Relates :  
Description
Consider the following sequence of events:

1.  The application is started, with the main JAR file as well as the JRE
    on a network drive.

2.  There is a network outage cause the network drive to become unavailable.

3.  An attempt to load a class that has not so far been used results in
    a ClassNotFoundException.

4.  Network connectivity is restored.

5.  Subsequent attempts to access the class from step 3 continue to fail 
    (they do not retry the file access).

The attached test case can be used to demonstrate the problem and RFE requirement. The test case loads a simple class from a jar file everytime you press the return key (loads "Test" class for 3-4 iterations and loads "Test2"
later in an infinite loop.

There are two scenarios that can fork off from the above:

Scenario I: The n/w connectivity is restored and you visually inspect the
n/w mapped folder to confirm that the data is accessible before hitting
return key to load a class again.

Scenario II: The n/w connectivity is NOT restored and we continue to hit the
return to load the class.

While the Scenario I is being addressed via Bug id # 5031910, we are submitting this RFE to address Scenario II as below:

The test case used to demonstrate both the current and expected
behaviour is the same one used with both scenarios. The expected
behaviour is to have a timer associated with "loadClass" API such that
if there were to be a network outage or network congestion/busy
conditions, the API would continue to try loading the class till the
timer expires or the data becomes available, whichever happens first.

Also, a meaningful exception should be associated with the fail/timeout 
case and the timeout value should be in milliseconds. 

Comments
EVALUATION Interesting request. But it's kind of chicken and egg problem. Say we add a new exception for such scenario, when this really happen, JVM needs to load the exception itself through a still unpluged network cable, what should we expect then? Basically the JVM doesn't support the notion of error recovery. That is, since the JRE is also located on a remote machine, when you unplug the network, meanwhile if the JVM is trying to access some JVM files such as those in rt.jar, it will encounter an IO error, as a result it throws a ClassDefNotFoundError. If the application really wants to recover from this kind of error, it can catch it and continue, or it can restart the JVM. In summary, this is not a bug.
08-12-2006