JMC-6100 and JMC-6152 Trigger Alerts

[Marcus Hirt]

Agreed. 

/M

- Excuse me if terse; sent from my phone.

> On 30 Oct 2018, at 14:17, Ken Dobson <kdobson at redhat.com> wrote:
> 
> 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
>> 
>> 
>> 
>>