Cargo remote deployment Glassfish 4.1 Fails GlassFish uses 100% CPU

Question

I have the following Problem with GlassFih 4.1 and Cargo.

I try to deploy an ear on a remote GlassFish 4.1 Server. Without success... Maven command: mvn cargo:redeploy The Glassfish Server takes 100% of the CPU and that's it. The Maven process remains blocked... I have tried on a remote ubuntu and on a remote windows server.

On the same remote server with Glassfish 3.1.2.2 the remote deployment works perfectly.

Did anybody hava the same issue, and did find a solution?

I guess that the following cargo config is ok, since it works with GF 3.1.2.2 (with deployment-client version 3.1.2.2 and containerId to glassfish3x).

<build>
    <plugins>
        <plugin>
              <groupId>org.codehaus.cargo</groupId>
              <artifactId>cargo-maven2-plugin</artifactId>
              <version>1.4.10</version>

              <executions>
                    <execution>
                        <id>glassfish-deploy</id>
                        <phase>pre-integration-test</phase>
                        <goals>
                            <goal>deploy</goal>
                         </goals>
                     </execution>
               </executions>

                    <configuration>
                        <container>
                            <containerId>glassfish4x</containerId>
                            <type>remote</type>
                            <log>target/cargo.log</log>
                            <logLevel>debug</logLevel>
                        </container>
                        <configuration>
                            <type>runtime</type>
                            <properties>
                                <cargo.hostname>servername</cargo.hostname>
                                <cargo.rmi.port>4848</cargo.rmi.port>
                                <cargo.remote.port>8080</cargo.remote.port>                           <cargo.glassfish.domain.name>domain1</cargo.glassfish.domain.name>
                                <cargo.runtime.args>force=true</cargo.runtime.args>
                                <cargo.protocol>https</cargo.protocol>
                                <cargo.remote.username>admin</cargo.remote.username>
                                <cargo.remote.password>admin</cargo.remote.password>
                            </properties>
                        </configuration>

                        <deployables>
                            <deployable>
                                <location>${project.build.directory}/${project.build.finalName}.${project.packaging}</location>
                                <properties>
                                    <name>${project.groupId}-${project.artifactId}-autodeploy</name>
                                </properties>
                                <type>ear</type>
                            </deployable>
                        </deployables>

                    </configuration>
                    <dependencies>
                        <dependency>
                            <groupId>org.glassfish.main.deployment</groupId>
                            <artifactId>deployment-client</artifactId>
                            <version>4.1</version>
                        </dependency>
                    </dependencies>
                </plugin>
            </plugins>

Answer 1

I'm experiencing the same issue and so do another user in thread deploying web app to external glassfish4 instance with maven cargo plugin

As you posted the JIRA bugs, there exists already a proposed solution. Try replacing Grizzly with patched version from the following thread.

https://java.net/jira/browse/GRIZZLY-1713

Answer 2

I have found that this is a bug in Glassfish 4.1.

See https://java.net/jira/browse/GLASSFISH-21180

See https://java.net/jira/browse/GLASSFISH-21196

So I decided to go for wildfly 8.1 and with the very good wildfly maven plugin.

Answer 3

There are some bugs in glassfish 4.1 as this point is already discussed in above answers by @pavel, these bugs also carry in payara 4.1.1.164, so if we are using the payara 4.1.1.164 then still we face these issues.

How to resolve

Use the same deployment client 4.1 and download the latest version of payara that is 4.1.1.171 from the following link, this version remove the two pointed issue. A solution is tested with the latest payara 4.1.1.171