sohami commented on a change in pull request #1504: DRILL-6792: Find the right
probe side fragment wrapper & fix DrillBuf…
URL: https://github.com/apache/drill/pull/1504#discussion_r229761029
##########
File path:
exec/java-exec/src/main/java/org/apache/drill/exec/physical/impl/filter/RuntimeFilterRecordBatch.java
##########
@@ -263,4 +260,41 @@ public void dump() {
+ "originalRecordCount={}, batchSchema={}]",
container, sv2, toFilterFields, originalRecordCount,
incoming.getSchema());
}
+
+ public enum Metric implements MetricDef {
+ FILTERED_ROWS, APPLIED_TIMES;
+
+ @Override
+ public int metricId() {
+ return ordinal();
+ }
+ }
+
+ public void updateStats() {
+ stats.setLongStat(Metric.FILTERED_ROWS, filteredRows);
+ stats.setLongStat(Metric.APPLIED_TIMES, appliedTimes);
+ }
+
+ private void timedWaiting() {
+ if (!enableRFWaiting || waited) {
+ return;
+ }
+ long startMs = System.currentTimeMillis();
+ while (current == null && batchTimes > 0) {
Review comment:
What's the reason of waiting after processing first batch ? Why not wait
just on condition **(current==null)** ?
Also it looks more like the design of this wait should be done using a
conditional variable. Where FragmentContext will signal the conditional
variable once Filter is set and this minor fragment thread will wait for
timeout or signal on that conditional variable. See
[here](https://docs.oracle.com/javase/8/docs/api/java/util/concurrent/locks/Condition.html#await-long-java.util.concurrent.TimeUnit-)
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
With regards,
Apache Git Services
