You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
1/2
Patch for 7.6 Only
Context:
MTR test ndb_restore_schema_tolerance fail sporadically
due to an error in DBUTIL. Util has a pool of prepared
operations that stores the Prepared Operations until they
are executed.
The pool has a fixed size of 6 where 4 are 'reserved' for
some operations on special tables, so, in fact, there
are only 2 available spaces in preparedOperationPoll.
When UTIL handles many preperareOperation simultaneous
the pool can get exhausted because it fails seize a free
object in the pool to store the new prepared op.
In a similar way, runningPrepares pool used by UTIL
to store the running prepare operations, can also be
exhausted. The pool size is 1 but there is nothing
preventing TRIX/DICT to send many UTIL_PREPARE_REQ
in parallel to UTIL. In that scenario UTIL will fail to
seize a free object for the new running prepare operation.
To check the described scenarios 2 new API level test are
added to test_event.
1 - ExhaustedPreparedPoolsApiOps:
Check if DBUTIL PreparedOperationPool and runningPrepares pool
get Exhausted when many getEvent operation run in parallel.
2 - ExhaustedPreparedPoolsInternalOps:
Checks that, if DBUTIL PreparedOperationPool and/or
runningPrepares get Exhausted due to events, internal
operations still succeed.
Test launches 32 threads running getEvent operation + 1 thread
running drop/create index in parallel in order to force UTIL
to handle many UTIL_PREPARE_REQ signals from both DICT and TRIX,
this way prepared op pool and runningPrepares pool can get
Exhausted since pool sizes are small and there is nothing
preventing UTIL to handle many UTIL_PREPARE_REQ simultaneously.
Test fails only when the operation that get the pool exhausted
is internal (from trix).
Change-Id: I12f3ff7f92ab4310dda32ecc0c825609720ce933
0 commit comments