[CARBONDATA-3123] Fixed JVM crash issue with CarbonRecordReader(SDK Reader). #2945
Conversation
…eader). **Problem:** As CarbonReaderBuilder is executed on the main thread therefore while Reader creation we are setting TaskId to threadlocal. When multiple readers are created using the split API then the TaskID for the last initialized reader would be overridden and all the readers will use the same TaskID. Due to this when one reader is reading and the other reader is freeing memory after its task completion the same memory block would be cleared and read at the same time causing SIGSEGV error. **Solution:** Do not set TaskID to thread local while Reader Initialization. ThreadLocalTaskInfo.getCarbonTaskInfo will take care of assigning new TaskID if not already present.
|
Build Success with Spark 2.1.0, Please check CI http://136.243.101.176:8080/job/ApacheCarbonPRBuilder2.1/1518/ |
|
Build Failed with Spark 2.2.1, Please check CI http://95.216.28.178:8080/job/ApacheCarbonPRBuilder1/1728/ |
|
Build Success with Spark 2.3.1, Please check CI http://136.243.101.176:8080/job/carbondataprbuilder2.3/9776/ |
|
retest this please |
|
Build Success with Spark 2.1.0, Please check CI http://136.243.101.176:8080/job/ApacheCarbonPRBuilder2.1/1520/ |
|
Build Success with Spark 2.2.1, Please check CI http://95.216.28.178:8080/job/ApacheCarbonPRBuilder1/1730/ |
|
Build Success with Spark 2.3.1, Please check CI http://136.243.101.176:8080/job/carbondataprbuilder2.3/9778/ |
|
LGTM |
| @@ -66,9 +63,6 @@ | |||
| this.readers = readers; | |||
| this.index = 0; | |||
| this.currentReader = readers.get(0); | |||
| CarbonTaskInfo carbonTaskInfo = new CarbonTaskInfo(); | |||
There was a problem hiding this comment.
Whether will it affect CSDK?
There was a problem hiding this comment.
The same issue would be there in CSDK as well as this would be called internally.
There was a problem hiding this comment.
You can try setting enable.unsafe.in.query.processing=true. I am not able to reproduce this on local. You can try on a 8 core machine.
There was a problem hiding this comment.
I also can't reproduce in local, my laptop has 8 cores and add
CarbonProperties.getInstance().addProperty("enable.unsafe.in.query.processing","true");
But SDK is run in single machine, so how to reproduce it？
Can you write the error in JIRA or this PR?
There was a problem hiding this comment.
@xubo245 i have updated the JIRA. Please check
There was a problem hiding this comment.
@xubo245 Please continue conversation on Jira. Code is already provided in jira.
There was a problem hiding this comment.
I tried the JIRA code in my laptop， JVM don‘'t crash...
…eader). Problem: As CarbonReaderBuilder is executed on the main thread therefore while Reader creation we are setting TaskId to threadlocal. When multiple readers are created using the split API then the TaskID for the last initialized reader would be overridden and all the readers will use the same TaskID. Due to this when one reader is reading and the other reader is freeing memory after its task completion the same memory block would be cleared and read at the same time causing SIGSEGV error. Solution: Do not set TaskID to thread local while Reader Initialization. ThreadLocalTaskInfo.getCarbonTaskInfo will take care of assigning new TaskID if not already present. This closes #2945
Problem:
As CarbonReaderBuilder is executed on the main thread therefore while Reader creation we are setting TaskId to threadlocal. When multiple readers are created using the split API then the TaskID for the last initialized reader would be overridden and all the readers will use the same TaskID.
Due to this when one reader is reading and the other reader is freeing memory after its task completion the same memory block would be cleared and read at the same time causing SIGSEGV error.
Solution:
Do not set TaskID to thread local while Reader Initialization. ThreadLocalTaskInfo.getCarbonTaskInfo will take care of assigning new TaskID if not already present.
Be sure to do all of the following checklist to help us incorporate
your contribution quickly and easily:
Any interfaces changed?
Any backward compatibility impacted?
Document update required?
Testing done
Please provide details on
- Whether new unit test cases have been added or why no new tests are required?
- How it is tested? Please attach test report.
- Is it a performance related change? Please attach the performance test report.
- Any additional information to help reviewers in testing this change.
For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.