Ivy
  1. Ivy
  2. IVY-1197

OutOfMemoryError duriong ivy:publish

    Details

    • Type: Bug Bug
    • Status: Open
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 2.0
    • Fix Version/s: None
    • Component/s: Core
    • Labels:
      None

      Description

      When publishing a large file, an OutOfMemoryError occurs.

      [ivy:publish] 	published ppg to XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
      
      BUILD FAILED
      /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:152: The following error occurred while executing this line:
      /export/build/hudson/jobs/ppg-rcp/workspace/ppg-rcp/com.daimler.ppg.rcp.builder/build-wrapper.xml:277: java.lang.OutOfMemoryError: Java heap space
      	at java.util.Arrays.copyOf(Arrays.java:2786)
      	at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
      	at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61)
      	at org.apache.ivy.util.FileUtil.copy(FileUtil.java:168)
      	at org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:200)
      	at org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
      	at org.apache.ivy.util.FileUtil.copy(FileUtil.java:140)
      	at org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:85)
      	at org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
      	at org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:219)
      	at org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:209)
      	at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:282)
      	at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:261)
      	at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:170)
      	at org.apache.ivy.Ivy.publish(Ivy.java:600)
      	at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:299)
      	at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
      	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
      	at sun.reflect.GeneratedMethodAccessor101.invoke(Unknown Source)
      	at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
      	at java.lang.reflect.Method.invoke(Method.java:597)
      	at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
      	at org.apache.tools.ant.Task.perform(Task.java:348)
      	at org.apache.tools.ant.Target.execute(Target.java:390)
      	at org.apache.tools.ant.Target.performTasks(Target.java:411)
      	at org.apache.tools.ant.Project.executeSortedTargets(Project.java:1397)
      	at org.apache.tools.ant.helper.SingleCheckExecutor.executeTargets(SingleCheckExecutor.java:38)
      	at org.apache.tools.ant.Project.executeTargets(Project.java:1249)
      	at org.apache.tools.ant.taskdefs.Ant.execute(Ant.java:442)
      	at org.apache.tools.ant.taskdefs.CallTarget.execute(CallTarget.java:105)
      	at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
      	at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
      
      Total time: 14 minutes 24 seconds
      Finished: FAILURE
      

      The size of the file that is being uploaded is: 687712714, so around 650-700MB.

      The publish task is part of a Hudson Ant build where the artefacts are published to an Artifactory repository at the end.
      I have given the Job 1300MB for the max heap size.

      It seems as if the whole file is loaded into memory for the upload.

        Issue Links

          Activity

          Hide
          Loren Kratzke added a comment -

          It is not at all obvious when looking at source code, and off the top of my head I do not have a quick answer to your question. Let me reproduce and document the steps I used to debug this. In the process I can provide exact details around the source files and methods that come together to make this bug happen.

          Show
          Loren Kratzke added a comment - It is not at all obvious when looking at source code, and off the top of my head I do not have a quick answer to your question. Let me reproduce and document the steps I used to debug this. In the process I can provide exact details around the source files and methods that come together to make this bug happen.
          Hide
          Maarten Coene added a comment -

          Thanks for the patch Loren, however, I don't see a real difference between your code and the code in FileUtil.copy(instream, out, null, false) regarding buffering the input. Could you point me where the problematic code in FileUtil.copy is?

          thanks,
          Maarten

          Show
          Maarten Coene added a comment - Thanks for the patch Loren, however, I don't see a real difference between your code and the code in FileUtil.copy(instream, out, null, false) regarding buffering the input. Could you point me where the problematic code in FileUtil.copy is? thanks, Maarten
          Hide
          Loren Kratzke added a comment - - edited

          I have attached a patch for HttpClientHandler.java. We have been using this patched version for a while now. It is working quite well for publishing 600MB+ files. We are using default heap and have experienced no issues so far.

          Show
          Loren Kratzke added a comment - - edited I have attached a patch for HttpClientHandler.java. We have been using this patched version for a while now. It is working quite well for publishing 600MB+ files. We are using default heap and have experienced no issues so far.
          Hide
          Antoine Levy-Lambert added a comment -

          I agree that it is a major problem. The solution provided by Loren Kratzke above looks simple enough, a patch would not hurt though.

          Show
          Antoine Levy-Lambert added a comment - I agree that it is a major problem. The solution provided by Loren Kratzke above looks simple enough, a patch would not hurt though.
          Hide
          Omair added a comment -

          Will this fix be incorporated into Ivy? Can someone provide an ETA?

          We tried publishing a ~600 MB file that failed with an ant process running with a 2 GB heap.. that's a problem

          Show
          Omair added a comment - Will this fix be incorporated into Ivy? Can someone provide an ETA? We tried publishing a ~600 MB file that failed with an ant process running with a 2 GB heap.. that's a problem
          Hide
          Loren Kratzke added a comment - - edited

          I have identified the root cause of the issue and I have a solution.

          Problem:
          JVM experiences java.lang.OutOfMemoryError during ivy:publish of a file greater than a few hundred MB.

          Cause:
          HttpURLConnection object as configured in org.apache.ivy.util.url.BasicURLHandler buffers the data before sending so as to calculate the content-length header value. This alone is bad however is likely aggravated by the default array resizing algorythm of the ByteArrayOutputStream used to buffer the data.

          The buffer starts small having a 32 byte capacity. When written to, it fills up and eventually it reaches maximum capacity. At this time a new buffer of twice the size is allocated. The content of the original buffer is copied to the new buffer and the old buffer is garbage collected. Lather, rinse, repeat.

          This works fine for small amounts of data however this is a major problem when talking about medium or large amounts of data. As the buffer size approaches 50% of the amount of free heap space, there will no longer be enough free RAM to allocate the new buffer. For example, if a 512MB buffer requires even one more byte of capacity, and there is one byte less than 1024MB free, then an attempt by ByteArrayOutputStream to allocate a new 1024MB buffer will fail with an OOME. This is a tragic waste of memory, especially if the content-length is already known and buffering is not even required (which is always the case for Ivy).

          Partial/Failed Solution Using HttpClient:
          For one reason or another, possibly to fix this issue, a reflection invocation is made by org.apache.ivy.util.url.URLHandlerRegistry for org.apache.commons.httpclient.HttpClient. Comments about Ivy-1197 instruct users to place HttpClient jar on the classpath (lib dir of Ant) to solve the OOME issue. Indeed, HttpClient (even the ancient version from 2005 used by Ivy) does not buffer the content and thus could avoid the OOME entirely, however there are three major problems with this solution.

          The first problem is that the trial invocation of HttpClient issued to detect availablility on the classpath fails rather silently by logging a vague message, and only if Ant is invoked in verbose mode. So somebody might drop the jar into the lib, see nothing happen, and wonder why.

          The second problem is that the trial invocation of HttpClient does indeed fail if all one does is drop the httpclient jar into the lib dir. This is because HttpClient requires two additional jars in order to instantiate: commons-logging and commons-codec.

          Adding these jars successfully triggers the Ivy code which substitutes the Apache HttpClient based org.apache.ivy.util.url.HttpClientHandler for the problematic URLConnectionHandler based org.apache.ivy.util.url.BasicURLConnectionHandler. But there is one more problem.

          The third problem is as follows: Apache docs in the HttpClient performance guide describe how to stream a request using a custom RequestEntity object. This object is capable of restarting the stream in the event of an interruption or an authentication request. They provide sample code. This code was copied into the Ivy HttpClientHandler however the block that writes directly to the OutputStream (without buffering) has been replaced by a call to the same method that URLConnectionHandler calls which buffers all of the data. The net effect is that the OOME persists because nothing about the upload has changed - the data is still buffered in a ByteArrayOutputStream.

          Complete/Successful Solution:
          In HttpClientHandler.FileRequestEntity.writeRequest(OutputStream) replace this line:

          FileUtil.copy(instream, out, null, false);

          with the original Apache sample code (slightly refactored to match the class):

          int length;
          byte[] buffer = new byte[64*1024];
          while ((length = instream.read(buffer)) != -1)

          { out.write(buffer, 0, length); }

          Then recompile Ivy. I recompiled using JDK 1.6 because that is the oldest VM around here.

          This fix only works when all of the following libraries are located in $ANT_HOME/lib directory:

          commons-httpclient.jar
          commons-logging.jar
          commons-codec.jar

          Those libraries are available in the apache-ivy-2.3.0-bin-with-deps distribution.

          Show
          Loren Kratzke added a comment - - edited I have identified the root cause of the issue and I have a solution. Problem: JVM experiences java.lang.OutOfMemoryError during ivy:publish of a file greater than a few hundred MB. Cause: HttpURLConnection object as configured in org.apache.ivy.util.url.BasicURLHandler buffers the data before sending so as to calculate the content-length header value. This alone is bad however is likely aggravated by the default array resizing algorythm of the ByteArrayOutputStream used to buffer the data. The buffer starts small having a 32 byte capacity. When written to, it fills up and eventually it reaches maximum capacity. At this time a new buffer of twice the size is allocated. The content of the original buffer is copied to the new buffer and the old buffer is garbage collected. Lather, rinse, repeat. This works fine for small amounts of data however this is a major problem when talking about medium or large amounts of data. As the buffer size approaches 50% of the amount of free heap space, there will no longer be enough free RAM to allocate the new buffer. For example, if a 512MB buffer requires even one more byte of capacity, and there is one byte less than 1024MB free, then an attempt by ByteArrayOutputStream to allocate a new 1024MB buffer will fail with an OOME. This is a tragic waste of memory, especially if the content-length is already known and buffering is not even required (which is always the case for Ivy). Partial/Failed Solution Using HttpClient: For one reason or another, possibly to fix this issue, a reflection invocation is made by org.apache.ivy.util.url.URLHandlerRegistry for org.apache.commons.httpclient.HttpClient. Comments about Ivy-1197 instruct users to place HttpClient jar on the classpath (lib dir of Ant) to solve the OOME issue. Indeed, HttpClient (even the ancient version from 2005 used by Ivy) does not buffer the content and thus could avoid the OOME entirely, however there are three major problems with this solution. The first problem is that the trial invocation of HttpClient issued to detect availablility on the classpath fails rather silently by logging a vague message, and only if Ant is invoked in verbose mode. So somebody might drop the jar into the lib, see nothing happen, and wonder why. The second problem is that the trial invocation of HttpClient does indeed fail if all one does is drop the httpclient jar into the lib dir. This is because HttpClient requires two additional jars in order to instantiate: commons-logging and commons-codec. Adding these jars successfully triggers the Ivy code which substitutes the Apache HttpClient based org.apache.ivy.util.url.HttpClientHandler for the problematic URLConnectionHandler based org.apache.ivy.util.url.BasicURLConnectionHandler. But there is one more problem. The third problem is as follows: Apache docs in the HttpClient performance guide describe how to stream a request using a custom RequestEntity object. This object is capable of restarting the stream in the event of an interruption or an authentication request. They provide sample code. This code was copied into the Ivy HttpClientHandler however the block that writes directly to the OutputStream (without buffering) has been replaced by a call to the same method that URLConnectionHandler calls which buffers all of the data. The net effect is that the OOME persists because nothing about the upload has changed - the data is still buffered in a ByteArrayOutputStream. Complete/Successful Solution: In HttpClientHandler.FileRequestEntity.writeRequest(OutputStream) replace this line: FileUtil.copy(instream, out, null, false); with the original Apache sample code (slightly refactored to match the class): int length; byte[] buffer = new byte [64*1024] ; while ((length = instream.read(buffer)) != -1) { out.write(buffer, 0, length); } Then recompile Ivy. I recompiled using JDK 1.6 because that is the oldest VM around here. This fix only works when all of the following libraries are located in $ANT_HOME/lib directory: commons-httpclient.jar commons-logging.jar commons-codec.jar Those libraries are available in the apache-ivy-2.3.0-bin-with-deps distribution.
          Hide
          Martin Sillence added a comment -

          I'm also seeing this issue with Java 7 (1.7.0_11) 32bit and dropping in commons-httpclient-3.0.1.jar to the lib folder makes no difference.
          Artefact is 400MB
          ivy 2.3.0
          publishing to a nexus repo

          Show
          Martin Sillence added a comment - I'm also seeing this issue with Java 7 (1.7.0_11) 32bit and dropping in commons-httpclient-3.0.1.jar to the lib folder makes no difference. Artefact is 400MB ivy 2.3.0 publishing to a nexus repo
          Hide
          Martin Todorov added a comment -

          Without httpclient on the classpath, the OOM error persists; with it it still takes the same amount of time as it did before. Could you, maybe, test it as well?

          Show
          Martin Todorov added a comment - Without httpclient on the classpath, the OOM error persists; with it it still takes the same amount of time as it did before. Could you, maybe, test it as well?
          Hide
          Maarten Coene added a comment -

          Martin,

          what stack trace are you talking about? The OOM error you posted earlier is not fixed. You will still get this error if you don't add commons-httpcient to Ivy's classpath. This is a bug in JDK1.4 and it will be solved if you decide to upgrade the minimal JDK supported by Ivy. However, with commons-httpclient you should not get this OOM! And with that extra modification we did, the upload speed should have improved.

          Could you verify that Ivy did use commons-httpclient to publish your big artifact?

          Maarten

          Show
          Maarten Coene added a comment - Martin, what stack trace are you talking about? The OOM error you posted earlier is not fixed. You will still get this error if you don't add commons-httpcient to Ivy's classpath. This is a bug in JDK1.4 and it will be solved if you decide to upgrade the minimal JDK supported by Ivy. However, with commons-httpclient you should not get this OOM! And with that extra modification we did, the upload speed should have improved. Could you verify that Ivy did use commons-httpclient to publish your big artifact? Maarten
          Hide
          Martin Todorov added a comment -

          After some more thorough tests, the issue appear to still not be resolved. What I'd seen as a successful deployment initially, appeared to only have been deploying to my local repository (on my machine). When I realized this, I re-ran the test and it still is failing with the same stack trace.

          Show
          Martin Todorov added a comment - After some more thorough tests, the issue appear to still not be resolved. What I'd seen as a successful deployment initially, appeared to only have been deploying to my local repository (on my machine). When I realized this, I re-ran the test and it still is failing with the same stack trace.
          Hide
          Martin Todorov added a comment -

          I think I actually hit the same issue again. Let me test it thoroughly on both a 32 and 64-bit SDK and get back to you. Could you, by any change, also give it a go with a file larger than 1.5 GB?

          Thanks!

          Show
          Martin Todorov added a comment - I think I actually hit the same issue again. Let me test it thoroughly on both a 32 and 64-bit SDK and get back to you. Could you, by any change, also give it a go with a file larger than 1.5 GB? Thanks!
          Hide
          Martin Todorov added a comment - - edited

          Maarten,

          Good news (sorry for the late reply): this indeed fixes the OOME! The artifact is uploaded within roughly 7 mins 30 secs.

          Two things:

          • If the credentials are incorrect, the file is still transferred before it fails. Perhaps this could be further polished up a bit, as it makes no sense to wait for it to fail late.
          • Since the file is 1.7 GB, it is obviously rather large. Ivy spends a huge amount of time filling my console with unnecessary dots. I have filed IVY-1411 and linked it to this bug, simply because for smaller artifacts, most people wouldn't even care to complain about it as a bug. However, with an artifact of this size, I am sure it is bringing at least a minute and a half to two of unnecessary over head. (As you can see, with Maven it's achieving the same effect in around five and a half minutes). If the progress must be displayed, the I think it would be sufficient to have 10 or 20 dots as a representation of the entire progress and Ivy can calculate the percentage.

          Could you please also look into these issues and give me an idea of when the next version of Ivy will be around?

          Many thanks for your time,

          Martin

          Show
          Martin Todorov added a comment - - edited Maarten, Good news (sorry for the late reply): this indeed fixes the OOME! The artifact is uploaded within roughly 7 mins 30 secs. Two things: If the credentials are incorrect, the file is still transferred before it fails. Perhaps this could be further polished up a bit, as it makes no sense to wait for it to fail late. Since the file is 1.7 GB, it is obviously rather large. Ivy spends a huge amount of time filling my console with unnecessary dots. I have filed IVY-1411 and linked it to this bug, simply because for smaller artifacts, most people wouldn't even care to complain about it as a bug. However, with an artifact of this size, I am sure it is bringing at least a minute and a half to two of unnecessary over head. (As you can see, with Maven it's achieving the same effect in around five and a half minutes). If the progress must be displayed, the I think it would be sufficient to have 10 or 20 dots as a representation of the entire progress and Ivy can calculate the percentage. Could you please also look into these issues and give me an idea of when the next version of Ivy will be around? Many thanks for your time, Martin
          Hide
          Martin Todorov added a comment -

          I will try this out tomorrow. Thanks!

          Show
          Martin Todorov added a comment - I will try this out tomorrow. Thanks!
          Hide
          Maarten Coene added a comment -

          Martin,

          thanks for the interesting links. We now set the 'http.protocol.expect-continue=true' header when using HttpClient.
          Could you give it a try? You can download snapshot builds here: https://builds.apache.org/view/A-F/view/Ant/job/Ivy/

          thanks,
          Maarten

          Show
          Maarten Coene added a comment - Martin, thanks for the interesting links. We now set the 'http.protocol.expect-continue=true' header when using HttpClient. Could you give it a try? You can download snapshot builds here: https://builds.apache.org/view/A-F/view/Ant/job/Ivy/ thanks, Maarten
          Hide
          Martin Todorov added a comment -

          Maarten,

          I did try it with the httpclient included in the latest Ivy. I added it to the classpath. Yes, indeed – the OOME is no longer there, but uploading the file takes a ridiculously long time. I tried with a file of 1.7 GB by deploying and artifact to Nexus with (first) Ivy and (then) Maven. Ivy took ~ 2 hr 30 mins, whereas under Maven 3.0.4 (without any extra configuration) it took ~ 5 min 25 sec. This is a huge difference, even with the httpclient on the classpath.

          I can't invest more time into analyzing this myself, but I can tell you what is most-likely happening. Check these two links for further details:

          Check the second link in regards to the http.protocol.expect-continue=true part. This explains what is happening. Apart from that, the PosterOutputStream is actually extending the ByteArrayOutputStream. If you have a look at it, it clones the byte array. This leads to using twice as much memory, as the file (at least).

          I think this should be properly addressed and that it is quite easily reproducible.

          Show
          Martin Todorov added a comment - Maarten, I did try it with the httpclient included in the latest Ivy. I added it to the classpath. Yes, indeed – the OOME is no longer there, but uploading the file takes a ridiculously long time. I tried with a file of 1.7 GB by deploying and artifact to Nexus with (first) Ivy and (then) Maven. Ivy took ~ 2 hr 30 mins, whereas under Maven 3.0.4 (without any extra configuration) it took ~ 5 min 25 sec. This is a huge difference, even with the httpclient on the classpath. I can't invest more time into analyzing this myself, but I can tell you what is most-likely happening. Check these two links for further details: http://maven.apache.org/docs/3.0.4/release-notes.html Maven 3.0.4's release notes http://maven.apache.org/guides/mini/guide-http-settings.html Guide to HTTP settings Check the second link in regards to the http.protocol.expect-continue=true part. This explains what is happening. Apart from that, the PosterOutputStream is actually extending the ByteArrayOutputStream. If you have a look at it, it clones the byte array. This leads to using twice as much memory, as the file (at least). I think this should be properly addressed and that it is quite easily reproducible.
          Hide
          Maarten Coene added a comment -

          Martin,
          if you add httpclient-3.x.jar to Ivy's classpath the problem should be solved.
          The OOM only occurs when Ivy uses the standard Java APIs.

          Regarding the slow upload speed when using httpclient, could you provide more info?
          (for instance the debug logging of httpclient)

          Maarten

          Show
          Maarten Coene added a comment - Martin, if you add httpclient-3.x.jar to Ivy's classpath the problem should be solved. The OOM only occurs when Ivy uses the standard Java APIs. Regarding the slow upload speed when using httpclient, could you provide more info? (for instance the debug logging of httpclient) Maarten
          Hide
          Martin Todorov added a comment - - edited

          This issue still exists in 2.3.0, despite the fact it is mentioned as fixed in the release notes of 2.3.0.

          It's ridiculous to not be able to deploy files which are larger than 64 MB. I have tried it with the proposed workaround with httpclient by adding it to the CLASSPATH. Yes, it somewhat works. It does upload the file. But in my case the file is over half a gig. Deploying that with Ivy takes roughly around 2 hr 30 mins, whereas under Maven (with no extra memory settings) this takes 5 mins 25 secs.

          Instead of using the HTTPURLConnection, can't you use the httpclient library, or an alternative implementation?

          Even on a 1.6.0_31 64-bit SDK with -Xms1700m -Xmx2048m you can't deploy a file larger than 512 MB, before getting:

          Exception in thread "main" java.lang.OutOfMemoryError: Java heap space
                  at java.util.Arrays.copyOf(Arrays.java:2786)
                  at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
                  at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61)
                  at org.apache.ivy.util.FileUtil.copy(FileUtil.java:183)
                  at org.apache.ivy.util.FileUtil.copy(FileUtil.java:162)
                  at org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:256)
                  at org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
                  at org.apache.ivy.util.FileUtil.copy(FileUtil.java:150)
                  at org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:84)
                  at org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
                  at org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:234)
                  at org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:216)
                  at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:275)
                  at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:254)
                  at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:166)
                  at org.apache.ivy.Ivy.publish(Ivy.java:615)
                  at org.apache.ivy.Main.run(Main.java:304)
                  at org.apache.ivy.Main.main(Main.java:179)
          

          I am deploying a zip file to Nexus. I tried the same with Maven 3.0.4 and it took five and a half minutes with no extra settings.

          I even tried further increasing the memory to twice the file size. That did not work either.

          This is a show-stopper for us to adopt Ivy.

          In theory, if this bug is fixed, how soon do you reckon the next version of Ivy will be released?

          Show
          Martin Todorov added a comment - - edited This issue still exists in 2.3.0, despite the fact it is mentioned as fixed in the release notes of 2.3.0. It's ridiculous to not be able to deploy files which are larger than 64 MB. I have tried it with the proposed workaround with httpclient by adding it to the CLASSPATH. Yes, it somewhat works. It does upload the file. But in my case the file is over half a gig. Deploying that with Ivy takes roughly around 2 hr 30 mins, whereas under Maven (with no extra memory settings) this takes 5 mins 25 secs. Instead of using the HTTPURLConnection, can't you use the httpclient library, or an alternative implementation? Even on a 1.6.0_31 64-bit SDK with -Xms1700m -Xmx2048m you can't deploy a file larger than 512 MB, before getting: Exception in thread "main" java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) at org.apache.ivy.util.FileUtil.copy(FileUtil.java:183) at org.apache.ivy.util.FileUtil.copy(FileUtil.java:162) at org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:256) at org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82) at org.apache.ivy.util.FileUtil.copy(FileUtil.java:150) at org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:84) at org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130) at org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:234) at org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:216) at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:275) at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:254) at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:166) at org.apache.ivy.Ivy.publish(Ivy.java:615) at org.apache.ivy.Main.run(Main.java:304) at org.apache.ivy.Main.main(Main.java:179) I am deploying a zip file to Nexus. I tried the same with Maven 3.0.4 and it took five and a half minutes with no extra settings. I even tried further increasing the memory to twice the file size. That did not work either. This is a show-stopper for us to adopt Ivy. In theory, if this bug is fixed, how soon do you reckon the next version of Ivy will be released?
          Hide
          Gordon Tyler added a comment -

          I was encountering this problem with our Jenson builds that use Ivy for dependency resolution and publishing, and using a trunk version of Ivy (built on 2011-04-20) with commons-httpclient appears to have solved the problem.

          Show
          Gordon Tyler added a comment - I was encountering this problem with our Jenson builds that use Ivy for dependency resolution and publishing, and using a trunk version of Ivy (built on 2011-04-20) with commons-httpclient appears to have solved the problem.
          Hide
          Maarten Coene added a comment -

          Mandie, from your stacktrace I can see you are not using commons-httpclient.
          The current trunk version could fix your problem if you add commons-httpclient to Ivy's classpath.

          Show
          Maarten Coene added a comment - Mandie, from your stacktrace I can see you are not using commons-httpclient. The current trunk version could fix your problem if you add commons-httpclient to Ivy's classpath.
          Hide
          Mandie Smith added a comment -

          I tried the latest code from SVN trunk and am still seeing the OutOfMemory error with both httpclient 3.0 and 3.1. I've noticed this does not seem to be affected by the ANT_OPTS values. The file I'm trying to publish is almost 900MB and I have tried using export ANT_OPTS="-Xmx2048m -Xms2048m" and seen no change in the results.

          Here's the stacktrace:

          BUILD FAILED
          ..... java.lang.OutOfMemoryError: Java heap space
          at java.util.Arrays.copyOf(Arrays.java:2786)
          at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
          at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61)
          at org.apache.ivy.util.FileUtil.copy(FileUtil.java:181)
          at org.apache.ivy.util.FileUtil.copy(FileUtil.java:160)
          at org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:217)
          at org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
          at org.apache.ivy.util.FileUtil.copy(FileUtil.java:148)
          at org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:84)
          at org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
          at org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:234)
          at org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:216)
          at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:281)
          at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:260)
          at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:172)
          at org.apache.ivy.Ivy.publish(Ivy.java:600)
          at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:311)
          at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
          at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
          at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:597)
          at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
          at org.apache.tools.ant.Task.perform(Task.java:348)
          at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68)
          at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
          at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:597)
          at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)
          at org.apache.tools.ant.Task.perform(Task.java:348)
          at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398)

          Here's the top of the MANIFEST.MF of my ivy.jar
          Manifest-Version: 1.0
          Ant-Version: Apache Ant 1.7.1
          Created-By: 17.0-b16 (Sun Microsystems Inc.)
          Specification-Title: Apache Ivy with Ant tasks
          Specification-Version: 2.2.x-local-20101001163220
          Specification-Vendor: Apache Software Foundation
          Implementation-Title: org.apache.ivy
          Implementation-Version: 2.2.x-local-20101001163220
          Implementation-Vendor: Apache Software Foundation
          Implementation-Vendor-Id: org.apache
          Extension-name: org.apache.ivy
          Build-Version: 2.2.x-local-20101001163220
          Main-Class: org.apache.ivy.Main

          Show
          Mandie Smith added a comment - I tried the latest code from SVN trunk and am still seeing the OutOfMemory error with both httpclient 3.0 and 3.1. I've noticed this does not seem to be affected by the ANT_OPTS values. The file I'm trying to publish is almost 900MB and I have tried using export ANT_OPTS="-Xmx2048m -Xms2048m" and seen no change in the results. Here's the stacktrace: BUILD FAILED ..... java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) at sun.net.www.http.PosterOutputStream.write(PosterOutputStream.java:61) at org.apache.ivy.util.FileUtil.copy(FileUtil.java:181) at org.apache.ivy.util.FileUtil.copy(FileUtil.java:160) at org.apache.ivy.util.url.BasicURLHandler.upload(BasicURLHandler.java:217) at org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82) at org.apache.ivy.util.FileUtil.copy(FileUtil.java:148) at org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:84) at org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130) at org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:234) at org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:216) at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:281) at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:260) at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:172) at org.apache.ivy.Ivy.publish(Ivy.java:600) at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:311) at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.taskdefs.Sequential.execute(Sequential.java:68) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) at org.apache.tools.ant.Task.perform(Task.java:348) at org.apache.tools.ant.taskdefs.MacroInstance.execute(MacroInstance.java:398) Here's the top of the MANIFEST.MF of my ivy.jar Manifest-Version: 1.0 Ant-Version: Apache Ant 1.7.1 Created-By: 17.0-b16 (Sun Microsystems Inc.) Specification-Title: Apache Ivy with Ant tasks Specification-Version: 2.2.x-local-20101001163220 Specification-Vendor: Apache Software Foundation Implementation-Title: org.apache.ivy Implementation-Version: 2.2.x-local-20101001163220 Implementation-Vendor: Apache Software Foundation Implementation-Vendor-Id: org.apache Extension-name: org.apache.ivy Build-Version: 2.2.x-local-20101001163220 Main-Class: org.apache.ivy.Main
          Hide
          Maarten Coene added a comment -

          I've applied a fix in SVN trunk based on your patch and the FileRequestEntity source code to keep Ivy compatible with httpclient 3.0.
          Could you please give it a try and post your feedback here?

          thanks,
          Maarten

          Show
          Maarten Coene added a comment - I've applied a fix in SVN trunk based on your patch and the FileRequestEntity source code to keep Ivy compatible with httpclient 3.0. Could you please give it a try and post your feedback here? thanks, Maarten
          Hide
          Torkild U. Resheim added a comment -

          Yes I noticed. However. Anyways, it is a small change and if you really need it you could always take the 2.2.x branch and do the required adjustments. I did a lot of testing today and did not discover anything suspicious.

          Show
          Torkild U. Resheim added a comment - Yes I noticed. However. Anyways, it is a small change and if you really need it you could always take the 2.2.x branch and do the required adjustments. I did a lot of testing today and did not discover anything suspicious.
          Hide
          Maarten Coene added a comment -

          Thanks for the patch.
          Problem is that FileRequestEntity is new since httpclient 3.1 and Ivy is compatible at the moment with 3.0.

          I guess we can change this minimal httpclient version requirement on trunk, but if we want this to be fixed in the 2.2.0 release as well, we have to use 3.0 compatible APIs.

          Show
          Maarten Coene added a comment - Thanks for the patch. Problem is that FileRequestEntity is new since httpclient 3.1 and Ivy is compatible at the moment with 3.0. I guess we can change this minimal httpclient version requirement on trunk, but if we want this to be fixed in the 2.2.0 release as well, we have to use 3.0 compatible APIs.
          Hide
          Torkild U. Resheim added a comment -

          Patch to fix the issue.

          Show
          Torkild U. Resheim added a comment - Patch to fix the issue.
          Hide
          Torkild U. Resheim added a comment -

          Try this instead:

          public void upload(File src, URL dest, CopyProgressListener l) throws IOException {
          HttpClient client = getClient(dest);

          PutMethod put = new PutMethod(normalizeToString(dest));
          put.setDoAuthentication(useAuthentication(dest) || useProxyAuthentication());
          try

          { put.setRequestEntity(new FileRequestEntity(src, "")); int statusCode = client.executeMethod(put); validatePutStatusCode(dest, statusCode, null); }

          finally

          { put.releaseConnection(); }

          }

          Show
          Torkild U. Resheim added a comment - Try this instead: public void upload(File src, URL dest, CopyProgressListener l) throws IOException { HttpClient client = getClient(dest); PutMethod put = new PutMethod(normalizeToString(dest)); put.setDoAuthentication(useAuthentication(dest) || useProxyAuthentication()); try { put.setRequestEntity(new FileRequestEntity(src, "")); int statusCode = client.executeMethod(put); validatePutStatusCode(dest, statusCode, null); } finally { put.releaseConnection(); } }
          Hide
          Torkild U. Resheim added a comment -

          I have the same problem and just tried a build from trunk and now I ALWAYS get the same exception when publishing:
          org.apache.commons.httpclient.ProtocolException: Unbuffered entity enclosing request can not be repeated.

          Show
          Torkild U. Resheim added a comment - I have the same problem and just tried a build from trunk and now I ALWAYS get the same exception when publishing: org.apache.commons.httpclient.ProtocolException: Unbuffered entity enclosing request can not be repeated.
          Hide
          Maarten Coene added a comment -

          Thanks for the stack trace.

          I've committed a patch into trunk which I hope will solve the problem.
          Could you please give it a try? If it works well we can integrate it in the upcoming 2.2.0 release.

          Maarten

          Show
          Maarten Coene added a comment - Thanks for the stack trace. I've committed a patch into trunk which I hope will solve the problem. Could you please give it a try? If it works well we can integrate it in the upcoming 2.2.0 release. Maarten
          Hide
          Kjell Schubert added a comment -

          >If you have OOM exceptions with commons-httpclient as well, could you post the stacktrace when such an OOM occurs?

          Here's one:

          [ivy:resolve] :: Ivy 2.2.0-rc1 - 20100629224905 :: http://ant.apache.org/ivy/ ::
          ...
          BUILD FAILED
          ... java.lang.OutOfMemoryError: Java heap space
          at java.util.Arrays.copyOf(Arrays.java:2786)
          at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94)
          at org.apache.commons.httpclient.methods.InputStreamRequestEntity.bufferContent(InputStreamRequestEntity.java:137)
          at org.apache.commons.httpclient.methods.InputStreamRequestEntity.getContentLength(InputStreamRequestEntity.java:187)
          at org.apache.commons.httpclient.methods.EntityEnclosingMethod.getRequestContentLength(EntityEnclosingMethod.java:336)
          at org.apache.commons.httpclient.methods.EntityEnclosingMethod.addContentLengthRequestHeader(EntityEnclosingMethod.java:406)
          at org.apache.commons.httpclient.methods.EntityEnclosingMethod.addRequestHeaders(EntityEnclosingMethod.java:374)
          at org.apache.commons.httpclient.HttpMethodBase.writeRequestHeaders(HttpMethodBase.java:2177)
          at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2060)
          at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096)
          at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398)
          at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171)
          at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397)
          at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323)
          at org.apache.ivy.util.url.HttpClientHandler.upload(HttpClientHandler.java:137)
          at org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82)
          at org.apache.ivy.util.FileUtil.copy(FileUtil.java:148)
          at org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:84)
          at org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130)
          at org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:227)
          at org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:209)
          at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:281)
          at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:260)
          at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:172)
          at org.apache.ivy.Ivy.publish(Ivy.java:600)
          at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:310)
          at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277)
          at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291)
          at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source)
          at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
          at java.lang.reflect.Method.invoke(Method.java:597)
          at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106)

          Using the standard dependencies: commons-codec-1.2.jar commons-httpclient-3.0.jar commons-logging-1.0.4.jar commons-vfs-1.0.jar ivy-2.2.0-rc1.jar jsch-0.1.31.jar oro-2.0.8.jar

          Show
          Kjell Schubert added a comment - >If you have OOM exceptions with commons-httpclient as well, could you post the stacktrace when such an OOM occurs? Here's one: [ivy:resolve] :: Ivy 2.2.0-rc1 - 20100629224905 :: http://ant.apache.org/ivy/ :: ... BUILD FAILED ... java.lang.OutOfMemoryError: Java heap space at java.util.Arrays.copyOf(Arrays.java:2786) at java.io.ByteArrayOutputStream.write(ByteArrayOutputStream.java:94) at org.apache.commons.httpclient.methods.InputStreamRequestEntity.bufferContent(InputStreamRequestEntity.java:137) at org.apache.commons.httpclient.methods.InputStreamRequestEntity.getContentLength(InputStreamRequestEntity.java:187) at org.apache.commons.httpclient.methods.EntityEnclosingMethod.getRequestContentLength(EntityEnclosingMethod.java:336) at org.apache.commons.httpclient.methods.EntityEnclosingMethod.addContentLengthRequestHeader(EntityEnclosingMethod.java:406) at org.apache.commons.httpclient.methods.EntityEnclosingMethod.addRequestHeaders(EntityEnclosingMethod.java:374) at org.apache.commons.httpclient.HttpMethodBase.writeRequestHeaders(HttpMethodBase.java:2177) at org.apache.commons.httpclient.HttpMethodBase.writeRequest(HttpMethodBase.java:2060) at org.apache.commons.httpclient.HttpMethodBase.execute(HttpMethodBase.java:1096) at org.apache.commons.httpclient.HttpMethodDirector.executeWithRetry(HttpMethodDirector.java:398) at org.apache.commons.httpclient.HttpMethodDirector.executeMethod(HttpMethodDirector.java:171) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:397) at org.apache.commons.httpclient.HttpClient.executeMethod(HttpClient.java:323) at org.apache.ivy.util.url.HttpClientHandler.upload(HttpClientHandler.java:137) at org.apache.ivy.util.url.URLHandlerDispatcher.upload(URLHandlerDispatcher.java:82) at org.apache.ivy.util.FileUtil.copy(FileUtil.java:148) at org.apache.ivy.plugins.repository.url.URLRepository.put(URLRepository.java:84) at org.apache.ivy.plugins.repository.AbstractRepository.put(AbstractRepository.java:130) at org.apache.ivy.plugins.resolver.RepositoryResolver.put(RepositoryResolver.java:227) at org.apache.ivy.plugins.resolver.RepositoryResolver.publish(RepositoryResolver.java:209) at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:281) at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:260) at org.apache.ivy.core.publish.PublishEngine.publish(PublishEngine.java:172) at org.apache.ivy.Ivy.publish(Ivy.java:600) at org.apache.ivy.ant.IvyPublish.doExecute(IvyPublish.java:310) at org.apache.ivy.ant.IvyTask.execute(IvyTask.java:277) at org.apache.tools.ant.UnknownElement.execute(UnknownElement.java:291) at sun.reflect.GeneratedMethodAccessor4.invoke(Unknown Source) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:597) at org.apache.tools.ant.dispatch.DispatchUtils.execute(DispatchUtils.java:106) Using the standard dependencies: commons-codec-1.2.jar commons-httpclient-3.0.jar commons-logging-1.0.4.jar commons-vfs-1.0.jar ivy-2.2.0-rc1.jar jsch-0.1.31.jar oro-2.0.8.jar
          Hide
          Maarten Coene added a comment -

          I have same concerns as mentioned here:
          https://issues.apache.org/bugzilla/show_bug.cgi?id=47660

          • Ivy is targetted at JDK1.4; these methods are JDK1.5+
          • Authentication is not handled automatically with streaming modes, I have no idea how to solve this...

          The problem is also that in JDK1.4 there is no other way to use streaming mode; this buffering PosterOutputStream is always used. The only option seems to use commons-httpclient.
          If you have OOM exceptions with commons-httpclient as well, could you post the stacktrace when such an OOM occurs?

          Show
          Maarten Coene added a comment - I have same concerns as mentioned here: https://issues.apache.org/bugzilla/show_bug.cgi?id=47660 Ivy is targetted at JDK1.4; these methods are JDK1.5+ Authentication is not handled automatically with streaming modes, I have no idea how to solve this... The problem is also that in JDK1.4 there is no other way to use streaming mode; this buffering PosterOutputStream is always used. The only option seems to use commons-httpclient. If you have OOM exceptions with commons-httpclient as well, could you post the stacktrace when such an OOM occurs?
          Hide
          Michael Rumpf added a comment -

          My last comment was a little bit early. The issue seems to be sporadic and we have it with a IBM 1.4.2 JDK and with a Sun 1.6.0 JDK, so the theory that this is a bug in the JDK has to be questioned. After adding commons-httpclient to the Ivy path the issue seems to be gone /at least sometimes, sorry, but I did not find a pattern yet).

          Additionally I found a hint that chunked streaming mode should used:
          http://forums.sun.com/thread.jspa?threadID=5387984

          See HttpURLConnection.setCHunkedStreamingMode():
          http://java.sun.com/j2se/1.5.0/docs/api/java/net/HttpURLConnection.html#setChunkedStreamingMode%28int%29

          Here is a patch for another Apache project as it seems that this mode can only be turned on when the server supports chunked streaming:
          https://issues.apache.org/bugzilla/show_bug.cgi?id=48726

          Show
          Michael Rumpf added a comment - My last comment was a little bit early. The issue seems to be sporadic and we have it with a IBM 1.4.2 JDK and with a Sun 1.6.0 JDK, so the theory that this is a bug in the JDK has to be questioned. After adding commons-httpclient to the Ivy path the issue seems to be gone /at least sometimes, sorry, but I did not find a pattern yet). Additionally I found a hint that chunked streaming mode should used: http://forums.sun.com/thread.jspa?threadID=5387984 See HttpURLConnection.setCHunkedStreamingMode(): http://java.sun.com/j2se/1.5.0/docs/api/java/net/HttpURLConnection.html#setChunkedStreamingMode%28int%29 Here is a patch for another Apache project as it seems that this mode can only be turned on when the server supports chunked streaming: https://issues.apache.org/bugzilla/show_bug.cgi?id=48726
          Hide
          Michael Rumpf added a comment -

          With the commons-httpclient version 3.1 this seems to work. Thanks for the hint!

          Show
          Michael Rumpf added a comment - With the commons-httpclient version 3.1 this seems to work. Thanks for the hint!
          Hide
          Maarten Coene added a comment -

          This appears to be a bug in the JDK.
          Could you try if you have the same problem when adding commons-httpclient-3,x to your Ivy classpath?

          Show
          Maarten Coene added a comment - This appears to be a bug in the JDK. Could you try if you have the same problem when adding commons-httpclient-3,x to your Ivy classpath?

            People

            • Assignee:
              Unassigned
              Reporter:
              Michael Rumpf
            • Votes:
              4 Vote for this issue
              Watchers:
              9 Start watching this issue

              Dates

              • Created:
                Updated:

                Development