kadirozde commented on code in PR #2302:
URL: https://github.com/apache/phoenix/pull/2302#discussion_r2467083129
##########
phoenix-core-server/src/main/java/org/apache/phoenix/hbase/index/IndexRegionObserver.java:
##########
@@ -633,13 +633,26 @@ public void
preBatchMutate(ObserverContext<RegionCoprocessorEnvironment> c,
+ "for current cluster, check configuration");
}
String tableName
- =
c.getEnvironment().getRegion().getRegionInfo().getTable().getNameAsString();
+ =
c.getEnvironment().getRegion().getRegionInfo().getTable().getNameAsString();
// We don't want to check for mutation blocking for the system ha
group table
if (!tableName.equals(SYSTEM_HA_GROUP_NAME)) {
// Extract HAGroupName from the mutations
final Set<String> haGroupNames =
extractHAGroupNameAttribute(miniBatchOp);
// Check if mutation is blocked for any of the HAGroupNames
for (String haGroupName : haGroupNames) {
+ //TODO: Below approach might be slow need to figure out
faster way, slower part is
Review Comment:
I assume the slowness will be observed for the very first mutation on the
specific HA group. When do we initialize an HA group store client? I am not
worried about slowness in updating the HA group system table. However, this
would be a concern if this slowness is also observed for user mutations. I
think we need to initialize an HA group store client before receiving the first
mutation. This may mean that we need to initiate initialization when the region
sever level Phoenix coproc starts possibly asynchronously.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
