[
https://issues.apache.org/jira/browse/PHOENIX-6687?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17537662#comment-17537662
]
ASF GitHub Bot commented on PHOENIX-6687:
-----------------------------------------
jpisaac commented on code in PR #1440:
URL: https://github.com/apache/phoenix/pull/1440#discussion_r873963217
##########
phoenix-core/src/main/java/org/apache/phoenix/query/QueryServicesOptions.java:
##########
@@ -223,11 +223,13 @@ public class QueryServicesOptions {
* HConstants#HIGH_QOS is the max we will see to a standard table. We go
higher to differentiate
* and give some room for things in the middle
*/
+ public static final int DEFAULT_SERVER_SIDE_PRIORITY = 500;
public static final int DEFAULT_INDEX_PRIORITY = 1000;
public static final int DEFAULT_METADATA_PRIORITY = 2000;
public static final boolean DEFAULT_ALLOW_LOCAL_INDEX = true;
public static final int DEFAULT_INDEX_HANDLER_COUNT = 30;
public static final int DEFAULT_METADATA_HANDLER_COUNT = 30;
+ public static final int DEFAULT_SERVERSIDE_HANDLER_COUNT = 30;
Review Comment:
@gjacoby126 Wasn't sure about that either, we will need some kind of
characterization/experiments to get some good empirical values. We can address
that via separate JIRA?
> The region server hosting the SYSTEM.CATALOG fails to serve any metadata
> requests as default handler pool threads are exhausted.
> ---------------------------------------------------------------------------------------------------------------------------------
>
> Key: PHOENIX-6687
> URL: https://issues.apache.org/jira/browse/PHOENIX-6687
> Project: Phoenix
> Issue Type: Bug
> Components: core
> Affects Versions: 5.1.0, 5.1.1, 4.16.1, 5.2.0, 5.1.2
> Reporter: Jacob Isaac
> Assignee: Jacob Isaac
> Priority: Major
> Fix For: 4.17.0, 5.2.0
>
> Attachments: stacktraces.txt
>
>
> When SYSTEM.CATALOG region server is restarted and the server is experiencing
> heavy metadata call volume.
> The stack traces indicate that all the default handler pool threads are
> waiting for the CQSI.init thread to finish initializing.
> The CQSI.init thread itself cannot proceed since it cannot complete the
> second RPC call
> (org.apache.phoenix.query.ConnectionQueryServicesImpl.checkClientServerCompatibility)
> due to thread starvation.
> For e.g
> The following
> [code|https://github.com/apache/phoenix/blob/3cff97087d79b85e282fca4ac69ddf499fb1f40f/phoenix-core/src/main/java/org/apache/phoenix/coprocessor/MetaDataEndpointImpl.java#L661]
> turned the getTable(..) into needing an additional server-to-server RPC call
> when initializing a PhoenixConnection (CQSI.init) for the first time on the
> JVM.
> It is well-known that server-to-server RPC calls are prone to deadlocking due
> to thread pool exhaustion.
--
This message was sent by Atlassian Jira
(v8.20.7#820007)
