[CARBONDATA-3958] Avoid blocking the loading task when the output queue poll timeout #3897
Conversation
|
Build Success with Spark 2.4.5, Please check CI http://121.244.95.60:12545/job/ApacheCarbon_PR_Builder_2.4.5/2106/ |
|
Build Failed with Spark 2.3.4, Please check CI http://121.244.95.60:12545/job/ApacheCarbonPRBuilder2.3/3847/ |
|
retest this please |
|
LGTM, |
|
@QiangCai as @ravipesala said since we are not using this, may be once after #3856 is merged, we can check and close this i think. |
|
Build Success with Spark 2.4.5, Please check CI http://121.244.95.60:12545/job/ApacheCarbon_PR_Builder_2.4.5/2110/ |
|
Build Success with Spark 2.3.4, Please check CI http://121.244.95.60:12545/job/ApacheCarbonPRBuilder2.3/3851/ |
|
@ravipesala @akashrn5 we can merge it also. In the future, other cases can use CarbonTableOutputFormat and this issue will not happen. |
QiangCai
changed the title
|
retest this please |
|
Build Success with Spark 2.3.4, Please check CI http://121.244.95.60:12545/job/ApacheCarbonPRBuilder2.3/3864/ |
|
Build Success with Spark 2.4.5, Please check CI http://121.244.95.60:12545/job/ApacheCarbon_PR_Builder_2.4.5/2123/ |
|
LGTM |
Why is this PR needed?
In some cases, the CDC merge tasks are blocked when data loading uses CarbonTableOutputFormat.getRecordWriter method. PR #3856 change the code to avoid using CarbonTableOutputFormat.getRecordWriter, CDC merge will not happen this issue again. But this issue maybe happen in other similar scenarios.
Because the poll method of the queue is time out in some cases, so the row batch in the queue will not be polled again.
After the queue is full, the queue blocks the writing task puts a new batch. Even if the queue is not full, it will also lose the row batch in the queue.
What changes were proposed in this PR?
If the output is not closed, it will poll a row batch in the loops till it gets a not null batch.
If the output is closed, it will break the loop.
Does this PR introduce any user interface change?
Is any new testcase added?