About JAVA$FILENAME_MATCH_LIST

[Wolfgang Kobarg-Sachsse]

Our Java application is writing some log files, using the setLogWriter method of the DriverManager class.

The problem is that the log files are locked for TYPE or EDIT until the application is shut down. But sometimes it is appropriate to see the content of the log files without stopping the application.

I tried the logical DECC$FILE_SHARING and set it to ENABLED. That avoided the "file is locked by another user" if trying to type it, but no content was shown, obviously no flushing took place, a $dir/size=all always shows something like 0/123.

The next approach was to use the logical JAVA$FILE_OPEN_MODE. Using the value 3 for this logical gave sharing, but the behaviour was identical to DECC$FILE_SHARING ENABLED.

Setting JAVA$FILE_OPEN_MODE to 2 gave a good result. Now we are able to type or edit the log files without shutting down the application. But I read that JAVA$FILE_OPEN_MODE = 2 needs many IOs which might impact the performance dramatically.

In http://h18012.www1.hp.com/java/documentation/1.4.2/ivms/docs/release_notes.html#sdk142-5newfeatures I have read this:

$ define JAVA$FILENAME_MATCH_LIST "*.*=shr=get,put,upi/rop=rea"

This is the equivalent of:

$ define java$file_open_mode 3

I tried many different keywords for JAVA$FILENAME_MATCH_LIST (the full list is here:
http://h71000.www7.hp.com/doc/83final/5763/5763pro_027.html#fab_rab_keywords_1 ) but I didn't find any equivalence of $define java$file_open_mode 2. Using JAVA$FILENAME_MATCH_LIST instead of JAVA$FILE_OPEN_MODE might enable me to restrict the sharing for my *.log files - if I could find the needed keywords to get the same behaviour as with JAVA$FILE_OPEN_MODE = 2.

Does anybody know whether this is possible and if, which keywords for JAVA$FILENAME_MATCH_LIST I shall use?

Regards,
Wolfgang

[marsh_1]

hi,

alternatively you could use backup/ign=inter to take a temporary point in time copy and check that with edit or typ and delete after.

[Wolfgang Kobarg-Sachsse]

Thanks for this hint. Unhappily I forgot to mention that I tried this already and that it does not solve the problem:

$ dir /siz=all

MYLOG.LOG;1 0/69

$ ty MYLOG.LOG

-RMS-E-FLK, file currently locked by another user

$ backup/ignore=interlock MYLOG.LOG x.log
%BACKUP-W-ACCONFLICT, MYLOG.LOG;1
is open for write by another user

$ dir /siz=all

MYLOG.LOG;1 0/69
X.LOG;1 0/69

$ ty x.log
$

Wolfgang

[marsh_1]

oops sorry missed the "obviously no flushing took place, a $dir/size=all always shows something like 0/123." - my bad

:-(

[marsh_1 · Accepted solution]

i found this in the java 1.4-2 manual , perhaps of use.


JAVA$FSYNC_INTERVAL

RMS buffers are not usually flushed to disk until the buffer is full or the program exits. If you want to view the contents of the file before the buffer is full (e.g., monitoring a logfile for output), the JAVA$FSYNC_INTERVAL logical allows you to define an interval after which all pending output is flushed to the disk with the command:

$ define/job JAVA$FSYNC_INTERVAL

For example,

$ define/job JAVA$FSYNC_INTERVAL 60 ! flush any pending output to disk every 60 seconds.

Note: Defining the logical to a very low value could cause performance degradation.

[Hoff]

The dearth of information on this topic and this little gem "We are working with HP C engineering to enhance the file-sharing features in the C RTL and the SDK" in the manuals together imply that this stuff isn't fully integrated and fully baked quite yet.

If you're in a relative hurry (and can have OpenVMS-specific code), consider punting on this and going direct to C here for your logs. We all know that works.

As for shr= options for testing, I'd likely go for just "get" here since you likely don't want to have other folks writing to the logs.

It might be feasible to use SET WATCH FILE /CLASS=ALL (with a small reproducer) to see what Java is doing with the file open processing. What options it is using, and allowing. RMS options such as SQO can affect sharing.

Given your apparent employer, I'd suggest using that position and checking with some of the "usual suspects" more directly. (You're probably in a better position to access point fixes and point updates and to lobby for changes than most of the rest of the readers here.)

[Hein van den Heuvel]

Wolfgang wrote>> obviously no flushing took place, a $dir/size=all always shows something like 0/123.

Actually... most data may well be 'flushed' (write behind) on the disk. Specifically every fully filled 'buffer' will have been written. The buffer size is likely equal to what $SHOW RMS indicated for MULTI-BLOCK-COUNT, typically 32 (16KB). The last/current buffer is not flushed, and more importantly, the EOF marker (and lock value block) is not updated to allow say $TYPE or $SEARCH to work.

Mark wrote>> alternatively you could use backup/ign=inter to take a temporary point in time copy and check that with edit or typ and delete after.

Actually... Did you ever try that? backup will happily ignore the interlock, but it will honor the EOF. Even with a file say 0/6432, with 6400 nicely written out blocks, it will not copy anything.
I have lobbied for /ignore=EOF but alas.
And yes $DUMP also needs a /ignore=(interlock, eof) but does not have one.

For desperate case I wrote a tool to 'clone' a file header, set eof on the clone, copy the cloned file, and remove the evidence. Works (for one header), but it is better to look for a 'real' solution with DECCRTL / JAVA settings if at all possible.

Cheers,
Hein.

[Hein van den Heuvel]

Hoff wrote>> Given your apparent employer

Ah, I did not notice this comment at first.
What Hoff means, is talk to Norm and perhaps Thilo and take it from there. :-).

Hein.

[Wolfgang Kobarg-Sachsse]

Mark,

thanks a lot for pointing me to the JAVA$FSYNC_INTERVAL logical. Using

$ define java$file_open_mode 3
$ define java$fsync_interval 10

is giving a good result, like java$file_open_mode 2, but a little bit less risky for the performance.

Still not any progress with JAVA$FILENAME_MATCH_LIST, will do some more tests, but if that will not work I'll be happy with the other solution.

Wolfgang

[Jim C Murray]

I am the engineer responsible for Oracle JDBC for Rdb. Our customers are requesting the ability to look at a live log file.

The JDBC drivers have the ability to close and re-open the logfiles online and this can be done so the old log can be typed but is a bit clunky to say the least.

I have tried the suggestions but
I must be doing something wrong as I tried
JAVA$FSYNC_INTERVAL = 10 and
java$file_open_mode = 3
(using JDK 1.5) but still could not TYPE the log file from the application.

Thanks for the other suggestions but we would prefer to have a solution to this problem that is supported by HP.

As for the suggestions of writing a C routine to log it, I am sorry but this wont fly, we use the DriverManager logging so that other JAVA applications may register interest in the log contents and would rather use a supported logging mechanism than roll our own.

I suppose I could investigate creating a stand-alone application that might use the DriverManager logging to capture the output as it is being written to the log file. Seems an overkill to solve something that should be fairly straight forward as SHARED READ.

Does anybody know if the JAVA$FILENAME_MATCH_LIST problem is a known bug ?
It certainly would be advantageous to be able to place the RMS attributes specifically on the one file we are interested rather than across the board.


Anyone know of any programmatic way within JAVA to do the same. I tried all sorts of things with open streams and file with/without locking etc in JAVA but could not find any combination that would allow the appropriate read sharing.

surely this cant be that difficult to do!

jim