Version 6 bug? Feature? When reading in a file
I installed the most recent JRE version 6. And now Java applet code which has been working for years has stopped functioning properly. Specifically the code which reads a file. It will read a file once, but subsequent reads seem to read from a cache rather than actually going out to read the file. This is a problem if the contents of the file have changed as users no longer get the latest update.
Is this caching a new feature? Is there a way to force the code not to read from the cache.
If anyone is interested, here is the readFile code. Maybe I have been doing something wrong all along and it is only now catching up to me in this newest JRE release?
//********************************************
// subroutine: readFile
//
// Functionality:
//Reading in simple text file
// - appends \n
// - result placed in public fileLines
//
// Returns:
//- 0 if no lines read or error
// - else lines read
//
// Affects:
// - public serverStatusMessage
//
//********************************************
public int readFile(String fileName) {
URLConnection conn = null;
DataInputStream data = null;
String line;
int i;
try {
// Set up connection
URL url = new URL("http://www.mywebsite.com/"+fileName);
conn = url.openConnection();
conn.connect();
// Read from a file
i = 0;
data = new DataInputStream(new BufferedInputStream(conn.getInputStream()));
while ((line = data.readLine()) != null) {
fileLines = line+"\n";
i++;
}
data.close();
}
catch (IOException e) {
serverStatusMessage = "Exception error while reading file";
return 0;
}
serverStatusMessage = "No errors while reading file";
return i;
}
[1879 byte] By [
CalEmboura] at [2007-11-27 2:30:17]
# 1
I have had a similar type of error.
I am using the remote scripting code that came with Microsoft Visual Studio 6.0 in Internet Explorer 6.0 under Windows XP Professional. This uses a Java class called RSAspProxyApplet to connect to the server, where VBScript code in an ASP page connects to a SQL Server 2005 database and returns information back to the calling page.
In JRE 1.5, this works fine. However, when I install JRE 1.6, I am sometimes not getting the correct return value.
After my investigation, I have determined the following:
1.Using the Java Console to clear the classloader cache clears the problem temporarily.
2.Reverting to JRE 1.5 by uninstalling 1.6 makes the problem go away entirely.
3.By adding code to store the result in a database prior to returning from the remote procedure, I determined when the remote procedure is actually executed and when it is not.
I have a web page that uses a remote procedure call to look up a city, county, and state from a zip code. If I navigate to the page and start trying zip codes, each new zip code is processed by the remote script and returns fine. However, if I repeat a zip code, the return value is the return value from the most recent actual previous call.
So for instance, if I choose 44503, 44512, 44513, 44515, 44516, 44512, then I get 4 city, county, state return values, followed by zip code not found for 44516 and then a repeat of zip code not found for 44512, even though it found the proper city the first time. I can then continue on with additional zip codes that I haven抰 tried before and those look up the correct city, county and state unless I repeat a zip code again.
If I go to another web page that uses the same call for the zip code lookup, the same zip codes fail, while new ones continue to work.
After experimenting, it appears that if the RSAspProxyApplet is to be called to connect to the same remote procedure with the same parameters, then it doesn抰 actually execute the call to the remote procedure, but instead returns the most recently returned value from a successful remote procedure call. This need not even be a call to the same remote function.
**********
In my case, I found a solution in making sure each call to the applet to start a new remote call was unique. To do this, I added 3 lines of code in the RS.HTM file in the _MSRS_buildURL function. I added them immediately after the line:
url += '&_mtype=execute';
My three lines add the number of milliseconds since 1/1/1970 as a dummy argument in the URL being passed as an argument to the applet.
var d = new Date();
var t = d.getTime();
url += '&_dummy=' + t.toString();
This apparently causes the JRE to recognize that it shouldn't be using a cached value since the argument is different from any previous call.
I would still appreciate knowing what is going on and perhaps the proper way to fix the problem. It does appear that some kind of caching is going on and this is a problem for two reasons:
1. It is returning the wrong cache value
2. As in the first post, the content could have changed between calls.
