[GitHub] carbondata pull request #3053: [WIP]JVM crash issue in snappy compressor

[qiuchenjian-2]

GitHub user akashrn5 opened a pull request:

    https://github.com/apache/carbondata/pull/3053

    [WIP]JVM crash issue in snappy compressor

    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.
   


You can merge this pull request into a Git repository by running:

    $ git pull https://github.com/akashrn5/incubator-carbondata jvmcrash

Alternatively you can review and apply these changes as the patch at:

    https://github.com/apache/carbondata/pull/3053.patch

To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:

    This closes #3053
   
----
commit b50d1c8b9c69565231cabf1d5dd507a006312a19
Author: akashrn5 <akashnilugal@...>
Date:   2019-01-07T11:04:48Z

    JVM crash issue in snappy compressor

----


---

[qiuchenjian-2]

Github user CarbonDataQA commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Build Success with Spark 2.1.0, Please check CI http://136.243.101.176:8080/job/ApacheCarbonPRBuilder2.1/2193/



---

[qiuchenjian-2]

Github user CarbonDataQA commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Build Failed  with Spark 2.3.2, Please check CI http://136.243.101.176:8080/job/carbondataprbuilder2.3/10449/



---

[qiuchenjian-2]

Github user CarbonDataQA commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Build Failed with Spark 2.2.1, Please check CI http://95.216.28.178:8080/job/ApacheCarbonPRBuilder1/2409/



---

[qiuchenjian-2]

Github user CarbonDataQA commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Build Success with Spark 2.1.0, Please check CI http://136.243.101.176:8080/job/ApacheCarbonPRBuilder2.1/2198/



---

[qiuchenjian-2]

Github user CarbonDataQA commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Build Success with Spark 2.2.1, Please check CI http://95.216.28.178:8080/job/ApacheCarbonPRBuilder1/2415/



---

[qiuchenjian-2]

Github user CarbonDataQA commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Build Success with Spark 2.3.2, Please check CI http://136.243.101.176:8080/job/carbondataprbuilder2.3/10455/



---

[qiuchenjian-2]

Github user qiuchenjian commented on a diff in the pull request:

    https://github.com/apache/carbondata/pull/3053#discussion_r245848950
 
    --- Diff: core/src/main/java/org/apache/carbondata/core/datastore/page/UnsafeFixLengthColumnPage.java ---
    @@ -369,7 +367,7 @@ public BigDecimal getDecimal(int rowId) {
     
       @Override
       public double[] getDoublePage() {
    -    double[] data = new double[getPageSize()];
    +    double[] data = new double[getEndLoop()];
    --- End diff --
   
    the return values of getPageSize() and getEndLoop seem to be same, when they are diff?


---

[qiuchenjian-2]

Github user qiuchenjian commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    i think the performance of rawCompress is better than compressLong,compressInt, can we find the root cause  of JVM crash？


---

[qiuchenjian-2]

Github user akashrn5 commented on a diff in the pull request:

    https://github.com/apache/carbondata/pull/3053#discussion_r245890379
 
    --- Diff: core/src/main/java/org/apache/carbondata/core/datastore/page/UnsafeFixLengthColumnPage.java ---
    @@ -369,7 +367,7 @@ public BigDecimal getDecimal(int rowId) {
     
       @Override
       public double[] getDoublePage() {
    -    double[] data = new double[getPageSize()];
    +    double[] data = new double[getEndLoop()];
    --- End diff --
   
    during complex type enhancement, to convert value and to get the value, pageSize was changed and new method called getEndLoop added, this was missed for double, so when double datatype is there in complex type data miss match happens, this is handled here. you can refer #2417


---

[qiuchenjian-2]

Github user akashrn5 commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    > i think the performance of rawCompress is better than compressLong,compressInt, can we find the root cause of JVM crash？
   
    i dont think there is much difference we get with timing, but problem is JVM crash happens randomly, since we get maxsizefor compression from snapy itself, we even allocated that memory sucessfully and passed the address to snappy, after that JVM crashed. This is very random. So better to remove that.


---

[qiuchenjian-2]

Github user CarbonDataQA commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Build Success with Spark 2.2.1, Please check CI http://95.216.28.178:8080/job/ApacheCarbonPRBuilder1/2436/



---

[qiuchenjian-2]

Github user CarbonDataQA commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Build Success with Spark 2.3.2, Please check CI http://136.243.101.176:8080/job/carbondataprbuilder2.3/10472/



---

[qiuchenjian-2]

Github user CarbonDataQA commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Build Success with Spark 2.1.0, Please check CI http://136.243.101.176:8080/job/ApacheCarbonPRBuilder2.1/2218/



---

[qiuchenjian-2]

Github user qiuchenjian commented on a diff in the pull request:

    https://github.com/apache/carbondata/pull/3053#discussion_r245982727
 
    --- Diff: core/src/main/java/org/apache/carbondata/core/datastore/page/UnsafeFixLengthColumnPage.java ---
    @@ -369,7 +367,7 @@ public BigDecimal getDecimal(int rowId) {
     
       @Override
       public double[] getDoublePage() {
    -    double[] data = new double[getPageSize()];
    +    double[] data = new double[getEndLoop()];
    --- End diff --
   
    get it， thank you


---

[qiuchenjian-2]

Github user CarbonDataQA commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Build Success with Spark 2.2.1, Please check CI http://95.216.28.178:8080/job/ApacheCarbonPRBuilder1/2440/



---

[qiuchenjian-2]

Github user CarbonDataQA commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Build Success with Spark 2.3.2, Please check CI http://136.243.101.176:8080/job/carbondataprbuilder2.3/10477/



---

[qiuchenjian-2]

Github user CarbonDataQA commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Build Success with Spark 2.1.0, Please check CI http://136.243.101.176:8080/job/ApacheCarbonPRBuilder2.1/2220/



---

[qiuchenjian-2]

Github user xuchuanyin commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    Does this PR fix two problems?
    If it is yes, better to separate it into two. And for the first problem, I'm also concerning about the performance decrease. The rawCompress can save some memory copy operations, that's why we add a check there and try to use that feature if the compressor supports that. It may needs more observations about the performance decreasement OR we can just add a switch there to control the behavior and it will be helpful for comparison.


---

[qiuchenjian-2]

Github user manishgupta88 commented on the issue:

    https://github.com/apache/carbondata/pull/3053
 
    @akashrn5 .....I agree with @xuchuanyin ....before merging the PR it is better to get the PR tested for performance. We can observe 2 things during the benchmark test - performance and compression ratio of rawcompress Vs compressDouble and then take the final decision


---