[ https://issues.apache.org/jira/browse/CSV-311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17825331#comment-17825331 ]
Gary D. Gregory commented on CSV-311: ------------------------------------- Hello [~cfeuersa] This issue is fixed in git master and snapshot builds in [https://repository.apache.org/content/repositories/snapshots/org/apache/commons/commons-csv/1.10.1-SNAPSHOT/] Please let us know how this works for your use case. > OutOfMemory for very long rows despite using column value of type Reader > ------------------------------------------------------------------------ > > Key: CSV-311 > URL: https://issues.apache.org/jira/browse/CSV-311 > Project: Commons CSV > Issue Type: Bug > Components: Printer > Affects Versions: 1.10.0 > Reporter: Christian Feuersaenger > Priority: Major > > Our application makes use of commons-csv (great software, thanks!) . > Recently, we got a support request because someone had unexpectedly large > column values in one CSV row - so large that our explicitly chosen limits on > the java heap did not suffice. > We analyzed the heap dump and found that a huge row was the culprit; the > stack trace in question is > {noformat} > Caused by -> java.lang.OutOfMemoryError: Java heap space > Arrays.copyOf:3537 > AbstractStringBuilder.ensureCapacityInternal:228 > AbstractStringBuilder.append:802 > StringBuilder.append:246 > CSVFormat.printWithQuotes:2127 > CSVFormat.print:1834 > CSVFormat.print:1783 > CSVPrinter.print:166 > CSVPrinter.printRecord:259 > CSVPrinter.printRecord:278 {noformat} > Note that we provide column values of type java.io.Reader as accepted by > org.apache.commons.csv.CSVFormat.print(Object, Appendable, boolean) . > The problem is that CSVFormat.print really supports java.io.Reader, but > despite just piping characters (possibly escaped/quoted) into the appendable > output stream, it reads everything into a StringBuilder which is then copied > to the appendable output stream. > Is there a way to improve this situation? We are working in a setup in which > java heap cannot be spend arbitrarily and we would rather have an approach > which works out of the box. > Thanks for looking into it! -- This message was sent by Atlassian Jira (v8.20.10#820010)