pavanprao

Let me just give you a history so that there will be more clarity. Initially we were using compression through Java ZIP libraries and most of the data is compressed...

As we are using Java 1.7 we will not be able to use java.util.Base64 which is added in Java 1.8. But I tried the changes using org.apache.commons.codec.binary.Base64 which is also...

Sure Rei. As suggested I tried running the above program with normal input data which works as expected. When I tried to run using the data which is encoded, we...

Attaching the standalone program also for reference. Thanks. ``` private void compressByLZ4(byte[] fileBytes) throws IOException { LZ4Factory factory = LZ4Factory.fastestInstance(); byte[] input = Base64.getDecoder().decode(fileBytes); System.out.println("Data Size After Decode: " +...

Yes, we are still facing the same error. I will be able to provide the encoding logic used for the sample data which was provided last time.

The Sample_4.txt and Sample_5.txt are compressed using JAVA ZIP Deflater package. When I am using JAVA ZIP Inflater package on the same files, it is working and able to decompress....

Agreed. It is acceptable that an exception is thrown. But it should not give OOM error while finding the decompressed length. This is what is causing the issue.

Understood. But I feel it is not a good practice to keep a static number and verify the decompressed length which may vary based on the input. If at all...

As we are not aware of the decompressed length we are relying on the LZ4 to calculate the length and then perform decompression. It would be better if LZ4 can...

Any updates on the queries? Also we found that we are not facing this error when we are using Snappy compression. But we wanted to use LZ4 as it is...