[ 
https://issues.apache.org/jira/browse/IGNITE-29229?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Egor Baranov updated IGNITE-29229:
----------------------------------
    Description: 
There is currently no way to detect AssertionError occurrences in the node JVM. 
These errors are frequently swallowed by catch (Throwable) blocks (500+ in the 
codebase), making them
     invisible during test runs.

    This change adds a LongAdderMetric named sys.AssertionErrorCount to 
GridMetricManager. The metric is backed by a JFR jdk.JavaErrorThrow event 
consumer (RecordingStream) that listens
     for thrown java.lang.AssertionError events and increments the counter. The 
stream is started/stopped with the manager lifecycle.

    The metric is exposed through all standard export channels (SQL metrics 
system view, JMX, REST) and requires no JVM agent.

  was:
h2. Description

    Currently, when AssertionError events occur in the Ignite node JVM (e.g. 
due to internal invariant violations triggered by assert statements), there is 
no built-in mechanism to
    count or detect them. These errors can be silently swallowed by 
catch(Throwable) blocks (500+ occurrences in the codebase), rethrown as wrapped 
exceptions, or terminate threads,
    making them difficult to track during test runs and production diagnostics.

    h3. Solution

    A new long-adder metric h1.AssertionErrorCount is added to the h1.sys 
metrics registry (fully qualified name: sys.AssertionErrorCount). The metric is 
backed by a JFR
    h1.jdk.JavaErrorThrow event consumer via 
h1.jdk.jfr.consumer.RecordingStream which is started and stopped as part of the 
h1.GridMetricManager lifecycle.

    The metric increments on every thrown h1.AssertionError regardless of 
whether the error is caught, rethrown, wrapped, or uncaught. This provides 100% 
detection coverage without
    requiring bytecode instrumentation or JVM agents.

    h3. Implementation details

     * Metric registered in h1.GridMetricManager constructor under h1.sys 
registry
     * JFR h1.RecordingStream started in h1.start(), closed in h1.stop()
     * Event listener filters on h1.thrownClass h1.equals 
java.lang.AssertionError
     * Metric exposed via all standard Ignite metric export channels (SQL 
h1.metrics system view, JMX, REST)

    h3. Files changed

     * 
modules/core/src/main/java/org/apache/ignite/internal/processors/metric/GridMetricManager.java
     * 
modules/core/src/test/java/org/apache/ignite/internal/processors/metric/GridMetricManagerAssertionMetricTest.java
     * 
modules/core/src/test/java/org/apache/ignite/testsuites/IgniteKernalSelfTestSuite.java

    h3. Verification

    Metric is visible via:
    {code:sql}
    SELECT * FROM metrics WHERE metric_name = 'sys.AssertionErrorCount';
    {/code}

    Unit test h1.GridMetricManagerAssertionMetricTest verifies both the metric 
metadata (name, description) and the increment behavior upon a thrown 
AssertionError. Test passes with and
     without global JFR enabled.


> Add AssertionErrorCount monitoring metric to detect AssertionError 
> occurrences in the JVM
> -----------------------------------------------------------------------------------------
>
>                 Key: IGNITE-29229
>                 URL: https://issues.apache.org/jira/browse/IGNITE-29229
>             Project: Ignite
>          Issue Type: New Feature
>            Reporter: Egor Baranov
>            Assignee: Egor Baranov
>            Priority: Major
>
> There is currently no way to detect AssertionError occurrences in the node 
> JVM. These errors are frequently swallowed by catch (Throwable) blocks (500+ 
> in the codebase), making them
>      invisible during test runs.
>     This change adds a LongAdderMetric named sys.AssertionErrorCount to 
> GridMetricManager. The metric is backed by a JFR jdk.JavaErrorThrow event 
> consumer (RecordingStream) that listens
>      for thrown java.lang.AssertionError events and increments the counter. 
> The stream is started/stopped with the manager lifecycle.
>     The metric is exposed through all standard export channels (SQL metrics 
> system view, JMX, REST) and requires no JVM agent.



--
This message was sent by Atlassian Jira
(v10.3.26#10030026)

Reply via email to