Unfortunately, this approach does not seem to work on many of our test
cluster machines. The creation of a "signal" file results in
"PermissionDenied".
The possible reason is the selinux configuration, or some other
permission related stuff. The container tries to create a new file on a
mount
Hi Daniil,
On 13/08/2019 9:24 am, Daniil Titov wrote:
Hi Robbin,
Thank you very much for reviewing this version of the fix! Based on your
findings
it seems as it makes sense to make a step back and continue with the
approach we took before in the previous version of the webrev (webrev.04),
a
Hi Robbin,
Thank you very much for reviewing this version of the fix! Based on your
findings
it seems as it makes sense to make a step back and continue with the
approach we took before in the previous version of the webrev (webrev.04),
and get more information about the impact on the startup
Here is an updated webrev:
http://cr.openjdk.java.net/~mseledtsov/8228960.01/
I am using a simple file-based mechanism to communicate between the
processes. The "EventGeneratorLoop" process creates a specific "signal"
file on a shared mounted volume, while the main test process waits for
the
Hi Nick,
Adding to Andrew comments, maybe the solution is to have the test extend
LingeredApp so it can produce a more reliable stack trace other than the
default one you get with LingeredApp. If that's too much trouble, I
don't mind the solution you came up with, but seems writing a
Lingered
Hi Adam,
It looks good to me.
thanks,
Chris
On 8/12/19 7:34 AM, Adam Farley8 wrote:
Hi All,
This is a known bug, mentioned
in
a code comment.
Here is the
Hi All,
This is a known bug, mentioned in a code comment.
Here is the fix for that bug.
Reviewers and sponsors requested.
Short version: if you set sun.boot.library.path to
something beyond a system's max path length, the
current code will return an empty string (rather than
printing a usefu
Hello Severin,
On 8/12/19 1:22 AM, Severin Gehwolf wrote:
Hi,
On Sun, 2019-08-11 at 07:25 -0700, Poonam Parhar wrote:
Hello,
The fix for this bug had to be backed out with '8227178: Backout of
8215523' because it had caused timeout failures for some of the CMS
tests. Those failures get resol
Hi Daniil,
I took a new deeper dive into this.
This line seems to have some issues:
if (ThreadTable::is_initialized() && thread->in_thread_table() &&
!thread->is_attaching_via_jni()) {
If you create new threads which attaches and then dies, the table will just keep
growing. So you must remov
Thanks Andrew. Can someone from the serviceability team check this is OK
to push?
Nick
On 08/08/2019 18:16, Andrew Dinn wrote:
Hi Nick,
On 08/08/2019 10:32, Nick Gasson wrote:
Bug: https://bugs.openjdk.java.net/browse/JDK-8229118
Webrev: http://cr.openjdk.java.net/~ngasson/8229118/webrev.0/
Poonam,
A new bug must be filed to redo the changes originally done under 8215523.
Thanks,
David
On 12/08/2019 6:22 pm, Severin Gehwolf wrote:
Hi,
On Sun, 2019-08-11 at 07:25 -0700, Poonam Parhar wrote:
Hello,
The fix for this bug had to be backed out with '8227178: Backout of
8215523' beca
Hi,
On Sun, 2019-08-11 at 07:25 -0700, Poonam Parhar wrote:
> Hello,
>
> The fix for this bug had to be backed out with '8227178: Backout of
> 8215523' because it had caused timeout failures for some of the CMS
> tests. Those failures get resolved by adding the following check
> before calling r
12 matches
Mail list logo
