You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@phoenix.apache.org by "Andrew Kyle Purtell (Jira)" <ji...@apache.org> on 2026/05/01 23:26:00 UTC

[jira] [Created] (PHOENIX-7826) MetadataGetTableReadLockIT wait for coprocessor swap to land

Andrew Kyle Purtell created PHOENIX-7826:
--------------------------------------------

             Summary: MetadataGetTableReadLockIT wait for coprocessor swap to land
                 Key: PHOENIX-7826
                 URL: https://issues.apache.org/jira/browse/PHOENIX-7826
             Project: Phoenix
          Issue Type: Sub-task
          Components: test
            Reporter: Andrew Kyle Purtell
            Assignee: Andrew Kyle Purtell
             Fix For: 5.4.0, 5.3.1


The {{testBlockedReadDoesNotBlockAnotherRead}} test installs a {{BlockingMetaDataEndpointImpl}} coprocessor on {{SYSTEM.CATALOG}} and expects a worker thread's query to hit it and signal a latch the main thread is waiting on, but {{TestUtil.addCoprocessor()}} only updates the master {{TableDescriptor}} and doesn't wait for region servers to reopen the region with the new coprocessor, so if the query reaches the old {{MetaDataEndpointImpl}} first the latch is never signaled and the main thread hangs until the Surefire/Failsafe fork times out. The fix is to add a helper that polls each {{SYSTEM.CATALOG}} region's coprocessor host (via {{{}findCoprocessor{}}}) for up to 10 seconds and call it after {{addCoprocessor}} so the coprocessor swap is guaranteed visible before the worker thread starts.



--
This message was sent by Atlassian Jira
(v8.20.10#820010)