Details
-
Type:
Bug
-
Status: Resolved
-
Priority:
Major
-
Resolution: Won't Fix
-
Affects Version/s: 1.5.9, 2.0.1
-
Fix Version/s: None
-
Component/s: Core
-
Labels:None
Description
AbstractHttpSenderConnectio.hasResponse reads the enter message into memory in order to ensure a message exists. When dealing with large messages this causes an OutOfMemoryError:
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 org.springframework.util.FileCopyUtils.copy(FileCopyUtils.java:113)
at org.springframework.util.FileCopyUtils.copyToByteArray(FileCopyUtils.java:164)
at org.springframework.ws.transport.http.AbstractHttpSenderConnection.hasResponse(AbstractHttpSenderConnection.java:72)
at org.springframework.ws.transport.AbstractSenderConnection.createTransportInputStream(AbstractSenderConnection.java:46)
at org.springframework.ws.transport.AbstractWebServiceConnection.receive(AbstractWebServiceConnection.java:86)
at org.springframework.ws.client.core.WebServiceTemplate.doSendAndReceive(WebServiceTemplate.java:548)
at org.springframework.ws.client.core.WebServiceTemplate.sendAndReceive(WebServiceTemplate.java:496)
at gov.ic.dia.cdir.client.CdirFetchServicesClientImpl.fetchWithAttachments(CdirFetchServicesClientImpl.java:160)
at gov.ic.dia.cdir.client.CommandLineClient.testFetchEnclosure(CommandLineClient.java:283)
at gov.ic.dia.cdir.client.CommandLineClient.main(CommandLineClient.java:129)
Activity
- All
- Comments
- Work Log
- History
- Activity
- Transitions
Thanks Marcus, that helped. If I set it to 2147483647 I don't get OOM on the client anymore.
However, I think, an attachment (at least in theory) can be larger than 2 GB, so it can be a problem.
Gyula Szalai
added a comment - Thanks Marcus, that helped. If I set it to 2147483647 I don't get OOM on the client anymore.
However, I think, an attachment (at least in theory) can be larger than 2 GB, so it can be a problem. If you do streaming, you often don't know any content-lenght in advance.
And you do not need to read the whole content into memory just to decide, whether there is content. This could easily be done using a PushbackInputStream, reading one byte and pushing it back.
Ralf Stuckert
added a comment - If you do streaming, you often don't know any content-lenght in advance.
And you do not need to read the whole content into memory just to decide, whether there is content. This could easily be done using a PushbackInputStream, reading one byte and pushing it back. Implementation using a PushbackInputStream in order to avoid reading the whole content
Ralf Stuckert
added a comment - Implementation using a PushbackInputStream in order to avoid reading the whole content Here is an implemenation using a PushbackInputStream: PatchedAbstractHttpSenderConnection.java
It works fine and allows streaming of large content without content-length header being set.
Ralf Stuckert
added a comment - Here is an implemenation using a PushbackInputStream: PatchedAbstractHttpSenderConnection.java
It works fine and allows streaming of large content without content-length header being set. And since the method hasResponse() is final, there is no chance to fix by inheritance.
Ralf Stuckert
added a comment - And since the method hasResponse() is final, there is no chance to fix by inheritance. 
This rather defeats the point of the various underlying streaming message facilities, such as StreamingWebServiceMessage or the Axiom message factory with payloadCaching disabled. It makes WebServiceTemplate unusable for large messages.