[jbosstools-issues] [JBoss JIRA] (JBIDE-19641) Big war deployment via management API gets stuck

[Kabir Khan (JIRA)]

    [ https://issues.jboss.org/browse/JBIDE-19641?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13079418#comment-13079418 ] 

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?


> Big war deployment via management API gets stuck
> ------------------------------------------------
>
>                 Key: JBIDE-19641
>                 URL: https://issues.jboss.org/browse/JBIDE-19641
>             Project: Tools (JBoss Tools)
>          Issue Type: Bug
>          Components: server
>    Affects Versions: 4.3.0.Alpha2
>            Reporter: Martin Malina
>            Assignee: Rob Stryker
>             Fix For: 4.3.0.Beta2
>
>         Attachments: stuck-deploy-eap-jstack-osx.log, stuck-deploy-eap-jstack-rhel.log, stuck-deploy-jstack-osx.log, stuck-deploy-jstack-rhel.log
>
>
> When you try to deploy some really big war (~500 MB) to EAP 6.3 via management api, it will not go through.
> This is a follow-up of JBIDE-19350 which previously reported this, but Rob eventually used that JIRA to fix a side issue - the stuck operation could not be canceled.



--
This message was sent by Atlassian JIRA
(v6.3.15#6346)