[
https://issues.apache.org/jira/browse/IGNITE-21562?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Maksim Zhuravkov updated IGNITE-21562:
--------------------------------------
Description:
During implementation of metrics for SQL were added set of tests. However added
set of tests is insufficient.
Let's add the following test scenarios:
Plan cache metrics:
sql.plan.cache.Misses - the number of cache misses.
sql.plan.cache.Hits - the number of cache hits.
For plan cache metrics:
* repeat for multiple queries that run concurrently. Check that metric
increased expected times. (check for plans cache hit and plans cache miss)
Cursor metrics:
sql.client.OpenCursors - the number of currently open cursors.
SQL API:
* start a query, call close on the ResultSet multiple times (the metric be
updated after the first close operation).
* start a query, start another query (the metric should increase by 2). Close
the ResultSet of the second query (the metric should decrease by 1). Close the
first ResultSet (the metric should return to its initial value).
* run metric checks for multiple concurrent operations.
* check that the metric returns to its initial value after a timeout (final
part is missing - see testMetricsDuringTimeouts).
* check that closing the session returns the metric to its initial value (no
standalone tests for this, tested in pre/post run checks).
JDBC API:
* For queries (execute, executeQuery methods of Statement/PreparedStatement):
** start a query (the metric should increase), obtain ResultSet, close it (the
metric should decrease).
** start a query, start another query (the metric should increase by 2).
Obtain ResultSet for both. Close the ResultSet of the second query (the metric
should decrease by 1). Close the first ResultSet (the metric should return to
its initial value).
** run metric checks for multiple queries concurrently.
** check that the metric returns to its initial value when a query returns an
error.
** check that the metric returns to its initial value after a timeout.
* For DML statements (via execute, executeUpdate, executeBatch methods of
Statement/PreparedStatement):
** execute DML statement (the metric should increase), close the statement
(the metric should return to its initial value).
** execute DML statement (the metric should increase), run another command
using the same statement, close the statement (the metric should return to its
initial value).
** repeat for multiple DML operations that run concurrently.
** run metric checks for multiple DML operations concurrently.
** check that the metric returns to its initial value when a DML operation
returns an error.
** check that the metric returns to its initial value after a timeout.
* Check check closing Statement/Connection also affects the metric and returns
it to its initial value.
was:
During implementation of metrics for SQL were added set of tests. However added
set of tests is insufficient.
Let's add the following test scenarios:
For plan cache metrics:
* repeat for multiple queries that run concurrently. Check that metric
increased expected times. (check for plans cache hit and plans cache miss)
Cursor metrics:
sql.client.OpenCursors - the number of currently open cursors.
SQL API:
* start a query, call close on the ResultSet multiple times (the metric be
updated after the first close operation).
* start a query, start another query (the metric should increase by 2). Close
the ResultSet of the second query (the metric should decrease by 1). Close the
first ResultSet (the metric should return to its initial value).
* run metric checks for multiple concurrent operations.
* check that the metric returns to its initial value after a timeout (final
part is missing - see testMetricsDuringTimeouts).
* check that closing the session returns the metric to its initial value (no
standalone tests for this, tested in pre/post run checks).
JDBC API:
* For queries (execute, executeQuery methods of Statement/PreparedStatement):
** start a query (the metric should increase), obtain ResultSet, close it (the
metric should decrease).
** start a query, start another query (the metric should increase by 2).
Obtain ResultSet for both. Close the ResultSet of the second query (the metric
should decrease by 1). Close the first ResultSet (the metric should return to
its initial value).
** run metric checks for multiple queries concurrently.
** check that the metric returns to its initial value when a query returns an
error.
** check that the metric returns to its initial value after a timeout.
* For DML statements (via execute, executeUpdate, executeBatch methods of
Statement/PreparedStatement):
** execute DML statement (the metric should increase), close the statement
(the metric should return to its initial value).
** execute DML statement (the metric should increase), run another command
using the same statement, close the statement (the metric should return to its
initial value).
** repeat for multiple DML operations that run concurrently.
** run metric checks for multiple DML operations concurrently.
** check that the metric returns to its initial value when a DML operation
returns an error.
** check that the metric returns to its initial value after a timeout.
* Check check closing Statement/Connection also affects the metric and returns
it to its initial value.
> Improve test coverage for SQL metrics
> -------------------------------------
>
> Key: IGNITE-21562
> URL: https://issues.apache.org/jira/browse/IGNITE-21562
> Project: Ignite
> Issue Type: Improvement
> Components: sql
> Reporter: Iurii Gerzhedovich
> Priority: Major
> Labels: ignite-3
>
> During implementation of metrics for SQL were added set of tests. However
> added set of tests is insufficient.
> Let's add the following test scenarios:
> Plan cache metrics:
> sql.plan.cache.Misses - the number of cache misses.
> sql.plan.cache.Hits - the number of cache hits.
> For plan cache metrics:
> * repeat for multiple queries that run concurrently. Check that metric
> increased expected times. (check for plans cache hit and plans cache miss)
> Cursor metrics:
> sql.client.OpenCursors - the number of currently open cursors.
> SQL API:
> * start a query, call close on the ResultSet multiple times (the metric be
> updated after the first close operation).
> * start a query, start another query (the metric should increase by 2).
> Close the ResultSet of the second query (the metric should decrease by 1).
> Close the first ResultSet (the metric should return to its initial value).
> * run metric checks for multiple concurrent operations.
> * check that the metric returns to its initial value after a timeout (final
> part is missing - see testMetricsDuringTimeouts).
> * check that closing the session returns the metric to its initial value (no
> standalone tests for this, tested in pre/post run checks).
> JDBC API:
> * For queries (execute, executeQuery methods of Statement/PreparedStatement):
> ** start a query (the metric should increase), obtain ResultSet, close it
> (the metric should decrease).
> ** start a query, start another query (the metric should increase by 2).
> Obtain ResultSet for both. Close the ResultSet of the second query (the
> metric should decrease by 1). Close the first ResultSet (the metric should
> return to its initial value).
> ** run metric checks for multiple queries concurrently.
> ** check that the metric returns to its initial value when a query returns
> an error.
> ** check that the metric returns to its initial value after a timeout.
> * For DML statements (via execute, executeUpdate, executeBatch methods of
> Statement/PreparedStatement):
> ** execute DML statement (the metric should increase), close the statement
> (the metric should return to its initial value).
> ** execute DML statement (the metric should increase), run another command
> using the same statement, close the statement (the metric should return to
> its initial value).
> ** repeat for multiple DML operations that run concurrently.
> ** run metric checks for multiple DML operations concurrently.
> ** check that the metric returns to its initial value when a DML operation
> returns an error.
> ** check that the metric returns to its initial value after a timeout.
> * Check check closing Statement/Connection also affects the metric and
> returns it to its initial value.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
