[
https://issues.apache.org/jira/browse/PHOENIX-7952?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Viraj Jasani updated PHOENIX-7952:
----------------------------------
Fix Version/s: 5.3.3
(was: 5.3.2)
> UpsertSelectIT is flaky due to a connection leak check using a global counter
> -----------------------------------------------------------------------------
>
> Key: PHOENIX-7952
> URL: https://issues.apache.org/jira/browse/PHOENIX-7952
> Project: Phoenix
> Issue Type: Sub-task
> Reporter: Andrew Kyle Purtell
> Assignee: Andrew Kyle Purtell
> Priority: Major
> Fix For: 5.4.0, 5.3.3
>
>
> {{UpsertSelectIT.testUpsertSelectOnDescToAsc}} intermittently fails in
> {{assertNoConnLeak}} with {{java.lang.AssertionError: expected:<0> but
> was:<1>}}. The test executes an auto commit server side {{DESC→ASC UPSERT
> INTO ... SELECT ...}} which drives {{MutationState}}'s parallel mutating
> iterator chain and may open auxiliary {{PhoenixConnections}} that are closed
> asynchronously on background threads. The test's {{@After}} hook reads a
> global {{GLOBAL_OPEN_PHOENIX_CONNECTIONS}} counter exactly once, immediately
> after the test body returns. If a background close path has not yet run its
> decrement by that moment, the counter still reads 1 and the hook reports a
> false connection leak. The race window widens when
> {{ENABLE_SERVER_SIDE_UPSERT_MUTATIONS}} is true, since more auxiliary
> connections are involved. The fix is to replace the single read with a
> bounded poll, for example, waiting up to 30 seconds for the counter to
> settle, following the same pattern used for {{MaxConcurrentConnectionsIT}},
> and/or to ensure that every auxiliary connection opened on the server-side
> {{UPSERT SELECT}} path is decremented before control returns to the caller.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
