[ https://issues.jboss.org/browse/JBIDE-19641?page=com.atlassian.jira.plugi... ] Kabir Khan edited comment on JBIDE-19641 at 6/15/15 6:21 PM: ------------------------------------------------------------- The problem is a combination of the client heap size and the copies done by the ByteArrayOutputStream when growing and (with a larger heap) when calling toByteArray() in InputStreamEntry.InMemoryEntry. {code} @Override public synchronized int initialize() throws IOException { final ByteArrayOutputStream os = new ByteArrayOutputStream(); try { StreamUtils.copyStream(original, os); //<-- Fails with small heap } finally { if(autoClose) { StreamUtils.safeClose(original); } } data = os.toByteArray(); //<- Fails with bigger heap return data.length; } {code} The simplest fix is to increase the heap size on the client. When I increase the heap to 4GB my 1GB deployment uploads fine. With a heap of 3GB it fails in the toByteArray() method, with a heap of 2GB it fails earlier in the method, when writing to it and it needs to grow. But that probably isn't the best way. There is also an alternative and unused implementation InputStreamEntry.CachingStreamEntry, which caches the input stream in a temporary file. The protocol seems to need the size, which is why we are doing these initial steps. Switching to that for everything is easy. Switching to it for somethings would require an extra field on InputStreamAttachements or something like that. Alternatively, if the operation attachment InputStreams are passed in as something implementing both InputStream and InputStreamEntry, AbstractModelControllerClient/createStreamEntries() will not create an intermediate InputStreamEntry. Thus an implementation for File, which uses the FileInputStream directly and gets the size from the File (removing the need to copy/cache the whole thing) should do the job. So perhaps a factory method for one of those would be nice to have somewhere? was (Author: kabirkhan): The problem is a combination of the client heap size and the copies done by the ByteArrayOutputStream when growing and (with a larger heap) when calling toByteArray() in InputStreamEntry.InMemoryEntry. {code} @Override public synchronized int initialize() throws IOException { final ByteArrayOutputStream os = new ByteArrayOutputStream(); try { StreamUtils.copyStream(original, os); //<-- Fails with small heap } finally { if(autoClose) { StreamUtils.safeClose(original); } } data = os.toByteArray(); //<- Fails with bigger heap return data.length; } {code} The simplest fix is to increase the heap size on the client. When I increase the heap to 4GB my 1GB deployment uploads fine. With a heap of 3GB it fails in the toByteArray() method, with a heap of 2GB it fails earlier in the method, when writing to it and it needs to grow. But that probably isn't the best way. There is also an alternative and unused implementation InputStreamEntry.CachingStreamEntry, which caches the input stream in a temporary file. The protocol seems to need the size, which is why we are doing these initial steps. Switching to that for everything is easy. Switching to it for somethings would require an extra field on InputStreamAttachements or something like that. Alternatively, if the operation attachment InputStreams are passed in as something implementing both InputStream and InputStreamEntry, AbstractModelControllerClient/createStreamEntries() will not create an additional InputStreamEntry. Thus an implementation for File, which uses the FileInputStream directly and gets the size from the File (removing the need to copy/cache the whole thing) should do the job. So perhaps a factory method for one of those would be nice to have somewhere? -- This message was sent by Atlassian JIRA (v6.3.15#6346)