Regarding options of error and dump file paths

[Koichi Sakata]

Hi David,

I’m sorry for the late reply. Thank you for your great advice.

 > Having an explicit option override the default directory option is a
 > good idea, but I'm not sure it is that clear cut. If you can specify a
 > relative directory and file name for a given dump file, might you not
 > want that to be relative to the specified default path, rather than
 > relative to the pwd?

I occasionally want to use a relative path from the specified default 
path. This usage might confuse the path where files are outputted and 
complicate to fix, so we probably should prohibit relative paths when we 
use the default path. We can choose the specification after we find 
detailed expectations.

 > And we actually have quite a lot of potential output files from:
 >   - GC (heap dumps)
 >   - JIT (replay files)
 >   - hs_err files
 >   - JFR (a number of files)
 >   - jcmd/dcmd dumps?
 >   - Unified logging?
 >
 > I think figuring out the exact details of how this should work, and
 > interact with all the different files involved may be more involved than
 > just prepending a path component.

I completely agree with you. To enable the new option needs a lot of our 
work, but that will improve convenience for users, I believe. Enabling 
easily to gathering error related files in one place helps us to 
troubleshoot. Not so many users set all these path options. If they use 
the new option, all they have to do will be sending files in the 
directory to their support personnel. In addition, they will get easier 
to keep files even on container environments.

 > I also think I would need to hear much greater demand, with detailed
 > usage expectations, before supporting this.

I think so, too. I'd like to hear various people's point of view.

Regards,
Koichi


On 2021/08/26 15:23, David Holmes wrote:
> Hi Koichi,
> 
> On 23/08/2021 1:29 pm, Koichi Sakata wrote:
>> Hi all,
>>
>> I'm writing to get feedback on my idea about options for error and 
>> dump file paths.
>>
>> First of all, we can specify several options related to error and dump 
>> files. For example, the HeapDumpPath option sets the heap dump file 
>> and the ErrorFile option sets the hs_error file.
>>
>> I've felt inconvenience about that because we need to write all path 
>> options to put those files in a specific directory. I also recognize 
>> that they are outputted in the working directory when I run an 
>> application with no options. But I'd like to keep them in any 
>> directory. So the new option that sets the directory where those files 
>> are outputted would be useful, I think.
>>
>> The new option helps us especially to run applications on containers 
>> like Docker, Kubernetes etc. If we run them without those existing 
>> options on containers, files will be put in the local directory of 
>> each container. We lose files after we operate the container such as 
>> deleting it. The option enables us to keep certainly all error and 
>> dump files if we just specify the path of the persistent volume for 
>> the new option.
>>
>> As a concrete example, when we specify -XX:ErrorAndDumpPath=/foo/bar/ 
>> (This option name is tentative), -XX:+HeapDumpOnOutOfMemoryError and 
>> -XX:StartFlightRecording etc., files are generated in the /foo/bar 
>> directory. From my point of view, the option will deal with the 
>> following files:
>> - heap dump file (java_pid%p.hprof)
>> - error log file (hs_err_pid%p.log)
>> - JFR emergency dumps (hs_err_pid%p.jfr, hs_oom_pid%p.jfr, 
>> hs_soe_pid%p.jfr)
>> - replay file (replay_pid%p.log)
>>
>> The existing path options should override the new option. If I set 
>> -XX:ErrorAndDumpPath=/foo/bar/ and -XX:HeapDumpPath=/foo/baz/, a heap 
>> dump file will be in the /foo/baz directory and other files will be 
>> created in the /foo/bar.
>>
>> I would like to hear your point of view. If some people agree to this 
>> idea, I will write a patch.
> 
> My initial reaction was that this seemed something better handled in a 
> launch script because I figured if you had complex needs in relation to 
> where these files were being placed, then you'd use a launch script to 
> help manage that anyway.
> 
> But I can see there would be some convenience to controlling the output 
> directory without also having to restate the default file names.
> 
> Having an explicit option override the default directory option is a 
> good idea, but I'm not sure it is that clear cut. If you can specify a 
> relative directory and file name for a given dump file, might you not 
> want that to be relative to the specified default path, rather than 
> relative to the pwd?
> 
> And we actually have quite a lot of potential output files from:
>   - GC (heap dumps)
>   - JIT (replay files)
>   - hs_err files
>   - JFR (a number of files)
>   - jcmd/dcmd dumps?
>   - Unified logging?
> 
> I think figuring out the exact details of how this should work, and 
> interact with all the different files involved may be more involved than 
> just prepending a path component.
> 
> I also think I would need to hear much greater demand, with detailed 
> usage expectations, before supporting this.
> 
> Just my 2c.
> 
> Cheers,
> David
> -----
> 
>> Regards,
>> Koichi