RFR (XS) : 8141641: Runtime: implement range for ErrorLogTimeout

[Thomas Stüfe]

Hi Colleen, Christian,

On Wed, Nov 11, 2015 at 12:42 AM, Coleen Phillimore <
coleen.phillimore at oracle.com> wrote:

>
>
> On 11/10/15 6:30 PM, Christian Thalinger wrote:
>
>> On Nov 10, 2015, at 11:22 AM, Coleen Phillimore <
>>> coleen.phillimore at oracle.com> wrote:
>>>
>>>
>>> I think the upper range should be much higher.   This sleep is also
>>> something that keeps the jvm alive if you are debugging and have multiple
>>> places that crash, and haven't set ShowMessageBoxOnError. Setting this flag
>>> to something very high will prevent the debugger from timing out with:
>>>
>>>           err.print_raw_cr("# [ timer expired, abort... ]");
>>>
>>> which is really annoying.
>>>
>> It is!  Since we are talking about this, why do we have that?
>>
>
> There's a comment that this sleeps 2 minutes to allow the hs_err_pid file
> to get printed before exit, which might be necessary, so we wouldn't want
> it to sleep indefinitely in that case.
>


The log timeout is very useful in our server scenarios, when a server node
shall come up after a crash in a defined time. But the 2 minutes hardwired
timeout was too small or too large depending on what you do, so we
introduced this parameter.



>
> I #if0 out this code whenever I'm debugging but specifying ErrorLogTimeout
> = very large would be a good workaround.
>
>
I would be fine with setting the default to max. The default now is 2
minutes because that was what was hard-coded before.

Regards, Thomas.

Coleen
>
>
>>    I'd almost suggest MAX_INT as the upper range, but maybe 60*60*60   60
>>> hours would do.
>>>
>>> Thanks,
>>> Coleen
>>>
>>> On 11/10/15 2:34 PM, gerard ziemski wrote:
>>>
>>>> hi all,
>>>>
>>>> Please review this small fix for JEP-245, which implements range for
>>>> the last new runtime flag.
>>>>
>>>>     bug: https://bugs.openjdk.java.net/browse/JDK-8141641
>>>> webrev: http://cr.openjdk.java.net/~gziemski/8141641_rev0
>>>>
>>>>
>>>> Thank you.
>>>>
>>>>
>>>>
>