Hi,
Can we fix this issue like this webrev?
http://cr.openjdk.java.net/~ysuenaga/JDK-8225690/proposal/
I could reproduce this issue with ConcAttachTest.java in it
on my laptop.
(Fedora 30 x64 on Hyper-V guest: Core i3-8145U x 2vcpu)
If we need to fix based on current implementation, I think
we need to use atomic operation.
But if we can refactor around here, we might be able to another approach
- e.g. using monitors/mutexes
Thanks,
Yasumasa
On 2019/06/21 5:49, David Holmes wrote:
Sorry it took me a while to understand the specifics of the problem. :)
David
On 20/06/2019 3:37 am, nijiaben wrote:
Yes Alan, I mean this
------------------?Original?------------------
*From: *?"Alan Bateman"<Alan.Bateman at oracle.com>;
*Date: *?Thu, Jun 20, 2019 02:54 PM
*To: *?"nijiaben"<nijiaben at perfma.com>; "David
Holmes"<david.holmes at oracle.com>;
"serviceability-dev"<serviceability-dev at openjdk.java.net>;
"jdk8u-dev"<jdk8u-dev at openjdk.java.net>;
"hotspot-runtime-dev"<hotspot-runtime-dev at openjdk.java.net>;
*Subject: *?Re: A Bug about the JVM Attach mechanism
On 20/06/2019 05:10, nijiaben wrote:
> :
> I know this mechanism, can we provide means of recovery to avoid
unavailability caused by accidental deletion?
>
Are you concerned about tmpreaper or cron jobs that periodically cleanup
/tmp? There may indeed be an issue for applications that run for weeks
or months. If someone is using jmap, jcmd or other tools using the
attach API then it will trigger the attach listener to start. When they
come back in a few weeks then the .java_pid<pid> file may have been
removed so they cannot attach. Is this what what you are pointing out?
-Alan
