JMC-6100 and JMC-6152 Trigger Alerts

[Ken Dobson]

Hi Marcus,

Yes, looking now it seems it only occurs in the standalone version, I'm
having a look into why that might be. Regarding the hprof dump, should we
be allowing another hprof dump to occur if the same trigger is triggered
again? It seems to me that there should be a better solution than throwing
an error because the file already exists. Something like appending a
timestamp similar to the way it's done when a trigger dumps a JFR file.

Ken Dobson

On Tue, Oct 30, 2018 at 2:24 PM Marcus Hirt <marcus.hirt at oracle.com> wrote:

> Hi Ken,
>
> I was sure that logging to file was appending. As a matter of fact, that
> is one
> of the demos I used to do - have the file open in a separate editor and
> watching
> it refresh itself as new events are coming in. If this behavior has
> changed, that
> is indeed a bug.
>
> I just ran it in Eclipse, and it even refreshes the editor as new data is
> coming
> In. ;)
>
> <--8<-->
> ========== Notification Alert! ==========
> A notification event has been triggered!
>
> Notification creation time was: Tue Oct 30 11:22:13 PDT 2018
> The notification source is: [11] LoadAndDeadlock (6496)
> The notification rule is: CPU Usage - JVM Process (Too High)
> Type description:
> attribute://java.lang:type=OperatingSystem/ProcessCpuLoad
> Rule trigger condition: value > 15 %
> The actual trigger value:
> 0.21656308360607793=========================================
>
> ========== Notification Alert! ==========
> A notification event has been triggered!
>
> Notification creation time was: Tue Oct 30 11:22:40 PDT 2018
> The notification source is: [11] LoadAndDeadlock (6496)
> The notification rule is: CPU Usage - JVM Process (Too High)
> Type description:
> attribute://java.lang:type=OperatingSystem/ProcessCpuLoad
> Rule trigger condition: value > 15 %
> The actual trigger value:
> 0.22926899255241157=========================================
>
> ========== Notification Alert! ==========
> A notification event has been triggered!
>
> Notification creation time was: Tue Oct 30 11:23:07 PDT 2018
> The notification source is: [11] LoadAndDeadlock (6496)
> The notification rule is: CPU Usage - JVM Process (Too High)
> Type description:
> attribute://java.lang:type=OperatingSystem/ProcessCpuLoad
> Rule trigger condition: value > 15 %
> The actual trigger value:
> 0.21038889067047212=========================================
>
> <--8<-->
>
> Could this be a problem that is limited to running the stand alone app?
>
> Kind regards,
> Marcus
>
> On 2018-10-30, 10:37, "jmc-dev on behalf of Ken Dobson" <
> jmc-dev-bounces at openjdk.java.net on behalf of kdobson at redhat.com> wrote:
>
>     Hi All,
>
>     I was having a quick look at
>     https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6100 which seem
> to be
>     a duplicate of
> https://bugs.openjdk.java.net/projects/JMC/issues/JMC-6152 .
>     It seems as if that is actually how it is intended to work as of right
> now,
>     as dumping an hprof file shouldn't provide an alert in JMC, just dump
> the
>     file to the location you've chosen which occurs correctly. The alert
> that
>     occurs the second time you turn the trigger on is an error for trying
> to
>     create a file that already exists as you had previously created it.
>
>     I was wondering if someone could provide some insight into whether we
> would
>     like to change this in some way, such as appending a timestamp to the
> hprof
>     to ensure file names aren't duplicated in case a user wanted to dump an
>     hprof more than once.
>     As well, logging a a trigger alert to a text file currently overwrites
> the
>     previous file so that is another option. That being said it seems odd
> to me
>     to keep just the most recent trigger alert rather than appending an
> alert
>     so that there's a log of the previous alerts.
>
>     Any insight into whether this is intended and why or whether this
> requires
>     changes would be appreciated.
>
>     Thanks,
>
>     Ken Dobson
>
>
>
>
>