OpenVMS: File.open of the same file concurrently only allows first reader to
read
---------------------------------------------------------------------------------
Key: JRUBY-6042
URL: https://jira.codehaus.org/browse/JRUBY-6042
Project: JRuby
Issue Type: Bug
Components: Core Classes/Modules
Affects Versions: JRuby 1.6.4
Environment: OpenVMS
java version "1.6.0"
Java(TM) SE Runtime Environment
Java HotSpot(TM) 64-Bit Server VM (build 14.3-b01, mixed mode)
Reporter: Ben Armstrong
When on OpenVMS JRuby 1.6.4 I open a File to read in the same process where I
have the same file open to read, I can only read the contents of the file from
the first open, not any subsequent opens. All other readers return zero bytes,
e.g.
irb(main):001:0> f=File.open('bg.tmp')
=> #<File:bg.tmp>
irb(main):002:0> f1=File.open('bg.tmp')
=> #<File:bg.tmp>
irb(main):003:0> f.read
=> "abc\ndef\nghi\n"
irb(main):004:0> f1.read
=> ""
The expected behaviour (demonstrable on Linux using JRuby 1.6.4 and MRI 1.8.7,
and on OpenVMS MRI 1.8.2) is that second and subsequent readers should be able
to read all bytes of the file:
>> f=File.open('bg.tmp')
=> #<File:bg.tmp>
>> f1=File.open('bg.tmp')
=> #<File:bg.tmp>
>> f.read
=> "abc\ndef\nghi\n"
>> f1.read
=> "abc\ndef\nghi\n"
The OpenVMS JDK 6.0 documentation indicates they have implemented a control for
file sharing, which is a little different under VMS from other operating
systems:
http://h18012.www1.hp.com/java/documentation/1.6.0/ivms/docs/user_guide.html#filesharing
However, none of the three documented values (0, 2 and 3) for this control (the
JAVA$FILE_OPEN_MODE logical name) change the behaviour reported above. Later in
the same document a more refined model to allow files matching a specific
filepath pattern to be opened with specific RMS file modes (which the
documentation says is equivalent to JAVA$FILE_OPEN_MODE 3) also fails in the
same way. See:
http://h18012.www1.hp.com/java/documentation/1.6.0/ivms/docs/user_guide.html#RMS
To make further headway on solving this problem, I need to articulate to HP
engineering what our problem is with their Java, but I lack the deep knowledge
of JRuby to express it in terms of a minimal failing pure Java test case. Our
naive attempt does not reproduce the problem:
import java.io.*;
import java.io.IOException;
public class p40ftest
{
public static void main(String[] args) {
if(args.length > 0) {
String val=null;
try
{
File f = new File(args[0]);
System.out.println("File Length[1]:
"+read_length(f));
// Attempt another open
File f2 = new File(args[0]);
System.out.println("File Length[2]:
"+read_length(f2));
} catch (NullPointerException npe) {
System.out.println("Opening file "+args[0] + "
has failed.");
}
}
}
public static long read_length(File f) {
StringBuilder contents = new StringBuilder();
BufferedReader input = null;
try {
input = new BufferedReader(new FileReader(f));
String line = null;
while((line=input.readLine()) != null) {
contents.append(line);
contents.append(System.getProperty("line.separator"));
}
} catch (FileNotFoundException fnfe) {
System.out.println("File Not Found: "+f.getName());
} catch(java.io.IOException ioe) {
System.out.println("IO Exception");
}
return contents.length();
}
}
And here are some test results:
$ java p40ftest ftest.java
File Length[1]: 883
File Length[2]: 883
Can someone help me accurately reproduce what JRuby is doing "under the hood"
in Java with multiple file opens of the same file? I started into a review of
the code and had a hard time cutting through all of the layers of abstraction
to distill from it a simple, pure Java reproducer.
Thanks,
Ben
p.s. It is interesting to note that if I repeat the above tests using the
default file sharing rule (which is described as "no file sharing" in the
documentation) but using two processes, one to first open f, and the second to
open f again (before the file is closed in the first process) then f.read
returns the expected results (the whole contents of the file) in both
processes! So maybe I am off on a tangent, chasing OpenVMS Java's file sharing
controls and there is some deeper problem here.
--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe from this list, please visit:
http://xircles.codehaus.org/manage_email
