9 Replies Latest reply on Mar 23, 2013 11:04 AM by Chris Lowe

    Very Slow Deployment: Remote Deployment AS7 / Seam 2.3 App

    Chris Lowe Apprentice

      Hello,

       

      I have a test for a Seam application running under Arquillian 1.0.3.  The remote container is for AS 7 (version 7.1.3.Final) and I'm deploying to a recent-ish build of AS 7.1.4.  The test completes successfully, but there is a long delay of 20-30 seconds prior to deployment to AS 7.

       

      In the test's static createDeployment method I output a timestamp to stdout.  I then monitor AS 7's logs for activity.  20-30 seconds later I see the app spring to life and the test executes.  During the initial delay, my CPU is maxing out a single core and a 10 MiB jar is gradually produced in my project's target folder (the project is Maven based) containing the basic deployment + arquillian apps.

       

      Any ideas on why there is a such a delay before deploying to AS7?  I have seen the following issue regarding the resolution of Maven dependencies.  This issue sounds very much like my setup and I have quite a lot of classes in my classpath, however I'm not resolving dependencies using the Maven resovler (at least not explicitly):

       

      https://community.jboss.org/message/731510

       

      I have tried running the test in debug mode from Eclise and randomly pausing the task a few times.  I just endup in a FutureTask will little contextual information.

       

      Any ideas on what the cause might be or where I can begin tracking this down?

       

      Regards,

       

      Chris.

        • 1. Re: Very Slow Deployment: Remote Deployment AS7 / Seam 2.3 App
          Chris Lowe Apprentice

          I've spent some time digging around at this and it seems that number of items are contributing to the 20-30 seconds delay I was experiencing.

           

          Two configuration items were causing some of the delay in my test's arquillian.xml, so for a quick win I removed the following offenders:

           

          Culprit A (responsible for 10 seconds' delay):

           

          <engine>

               <property name="deploymentExportPath">target/</property>

          </engine>

           

           

          Culprit B (responsible for 3 seconds' delay or so - my test is using remote container, so this is not required):

           

          <container qualifier="jboss" default="true">

               <configuration>

              <property name="javaVmArguments">-server -XX:+TieredCompilation -Xmx1024m -XX:MaxPermSize=512m -Xverify:none</property>

              <property name="jbossHome">C:\bin\java\jboss\as\jboss-as-7.1.4.Final-SNAPSHOT</property>

              <property name="serverConfig">standalone-full.xml</property>

               </configuration>

          </container>

           

          With the above configuration removed I am still left with a 11 second delay.  I've spent some time poring through some of the test bootstrap process and I've created a unit test based on the Arquillian getting started guide that simulates what I observed to be some slow sections in that process.

           

          From my test, I measured a total initialisation time of 11278ms where most of the delay comes from two sections:

           

          2527ms spent auxiliary archive loading; and

          8533ms spent writing the application archive to a byte array ready for sending to JBoss.

           

          Here is some example output from my test:

           

          Time before invoking createDeployment() = 0ms

          Created EAR depoloyment in 113ms

          Manager created in 73ms

          Load AuxiliaryArchiveAppender instances loaded in 4ms

          9 auxiliary archives loaded in 2527ms

          Auxiliary archives added to deployment in 28ms

          Application archive written to byte stream in 8533ms

          TOTAL time to complete initialisation = 11278ms. Final test EAR deployment size = 10076427 bytes

           

          Some observations that I noted is that the auxiliary load time, final EAR deployment size and write time are sensitive to dependencies being present on the classpath.  My test has a dependency on Arquillian persistence and the arquillain-persistence.jar that is added to the final EAR deployment varies in size massively.  In a vanilla test with just the orignal dependencies from the getting started guide, arquillian-persistence.jar was about 4.5MiB.  With Seam and JMeter dependencies on the classpath, that file ballooned to 9MiB with files brought in from org.apache (amongst others).  Those arquillian jar files are generated on the fly, compressed, added to the application archive, recompressed when added to the EAR and finally written to a ByteArrayOutputStream with default parameters (inefficient) for internal deployment.

           

          Is there somewhere I can send my test project?  Should I raise a Jira case for this?

           

          Regards,

           

          Chris.

          • 2. Re: Very Slow Deployment: Remote Deployment AS7 / Seam 2.3 App
            Karel Piwko Master

            Hi Chris,

             

            I'm convinced that performance issues should be addressed: As it is not clear whether the problem is in Core or in AS7 adaptor, I suggest you to fill an issue at https://issues.jboss.org/browse/ARQ.

             

            You can post your project or at least pom.xml there. Then I can verify how much is ShrinkWrap Maven Resolver responsible, or it is core and redirect the issue for you

             

            Keep testing,

             

            Karel

            • 3. Re: Very Slow Deployment: Remote Deployment AS7 / Seam 2.3 App
              Chris Lowe Apprentice

              Thank you, Karel.  I've created the following issue:

               

              https://issues.jboss.org/browse/ARQ-1318

               

              Let me know if I can help in any way.

               

              Chris.

              • 4. Re: Very Slow Deployment: Remote Deployment AS7 / Seam 2.3 App
                Michal Matloka Newbie

                It sounds a bit it might be connected to ShrinkWrap Resolvers. Lately in 2.0.0-beta2 there were performed some performance improvements concerning classpath reading ( https://issues.jboss.org/browse/SHRINKRES-56 https://community.jboss.org/message/731510 ). But I'm not sure if the same problems occured on previous ShrinkWrap Resolvers version used in Arquillian BOM.

                • 5. Re: Very Slow Deployment: Remote Deployment AS7 / Seam 2.3 App
                  Chris Lowe Apprentice

                  Thanks for the reply Michal.  I had tried using  using the beta 2 resolvers prior to making the original post but unfortunately this made no difference to my times.

                   

                  Working with the Maven project attached to https://issues.jboss.org/browse/ARQ-1318, I verified what I had previously tried by adding the following dependency as the first entry in my pom (as to override dependencies of subsequently declared entries):

                   

                  <dependency>

                            <groupId>org.jboss.shrinkwrap.resolver</groupId>

                            <artifactId>shrinkwrap-resolver-impl-maven</artifactId>

                            <version>2.0.0-beta-2</version>

                  </dependency>

                   

                  Running "mvn dependency:tree -Parquillian-jbossas-remote" confirms that this is the only Maven resolver in action:

                   

                  $ mvn dependency:tree -Parquillian-jbossas-remote | grep -i maven

                  [WARNING] For this reason, future Maven versions might no longer support building such malformed projects.

                  [INFO] --- maven-dependency-plugin:2.1:tree (default-cli) @ arquillian-tutorial ---

                  [INFO] +- org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-impl-maven:jar:2.0.0-beta-2:compile

                  [INFO] |  +- org.jboss.shrinkwrap.resolver:shrinkwrap-resolver-api-maven:jar:1.0.0-beta-7:compile (version managed from 2.0.0-beta-2)

                  [INFO] |  +- org.apache.maven:maven-aether-provider:jar:3.0.4:compile

                  [INFO] |  +- org.apache.maven:maven-model:jar:3.0.4:compile

                  [INFO] |  +- org.apache.maven:maven-model-builder:jar:3.0.4:compile

                  [INFO] |  +- org.apache.maven:maven-repository-metadata:jar:3.0.4:compile

                  [INFO] |  +- org.apache.maven:maven-settings:jar:3.0.4:compile

                  [INFO] |  +- org.apache.maven:maven-settings-builder:jar:3.0.4:compile

                  [INFO] |  +- org.apache.maven.wagon:wagon-provider-api:jar:2.2:compile

                  [INFO] |  +- org.apache.maven.wagon:wagon-file:jar:2.2:compile

                  [INFO] |  \- org.apache.maven.wagon:wagon-http-lightweight:jar:2.2:compile

                  [INFO] |     \- org.apache.maven.wagon:wagon-http-shared4:jar:2.2:compile

                   

                  ...

                   

                  Timings were broadly similar:

                   

                  Time before invoking createDeployment() = 0ms

                  Created EAR depoloyment in 92ms

                  Manager created in 67ms

                  Load AuxiliaryArchiveAppender instances loaded in 2ms

                  9 auxiliary archives loaded in 3013ms

                  Auxiliary archives added to deployment in 21ms

                  Application archive written to byte stream in 8309ms

                  TOTAL time to complete initialisation = 11505ms. Final test EAR deployment size = 10076607 bytes

                   

                  Regards,

                   

                  Chris.

                  • 6. Re: Very Slow Deployment: Remote Deployment AS7 / Seam 2.3 App
                    Chris Lowe Apprentice

                    I've taken a different approach to this problem and decided to have a go at leveraging AS7's amazing module system.  With a few tweaks here and there, I've managed to get Arquillian to side step the auto-packaging of dependent classes and install required dependencies as AS7 modules.

                     

                    The upshot is that a test now has a much reduced preparation overhead and from launching the test I see a difference between the invocation of the createDeployment() method and deployment activity in the AS7 logs of about 2 seconds. After a couple of runs, the target AS7 server is warmed up and the whole test cycle (from selecting Run in Eclipse to seeing a green result from a suite of 8 unit tests) completes in about 10 seconds.  Most of that time is spent in AS7 deploying the app  - the app is a reasonable size and is running database init scripts. Also, the tests use Arquillian Persistence to pre-populate test data.

                     

                    From my point of view, this is a resounding success for my testing workflow.  Very workable.  A few questions stem from this:

                     

                    Are there any plans to officially support the execution of tests via the AS7 remote container that support AS7 modules?

                     

                    In the short term, would it be possible to have an annotation or aquillian.xml setting to indicate that dependencies are provided and should not be processed by Aquillian?  I.e. turn of the shrinkwrap dectection/packaging of dependencies.

                     

                    Would it be possible to control the compression level in shrinkwrap's ZipExporters implementation?  The compression in this use case is unnecessary and slows down the deployment quite a bit.

                     

                    With the above in place, Arquillian and shrinkwrap support *manually* configured AS7 Aquillian modules nicely and executing speed is much improved.  Going forwards, I'm sure the AS7 modules could, say,  be derived and installed using a custom Maven plug-in with on-the-fly module configuration handled by the Aquillain remote AS7 container.

                     

                    Finally, where can I find the source for the AS7 containers?  The code located at https://github.com/arquillian/arquillian-container-jbossas only seems to support up to JBoss 6.

                     

                    Cheers,

                     

                    Chris.

                    • 7. Re: Very Slow Deployment: Remote Deployment AS7 / Seam 2.3 App
                      Heiko Tappe Newbie

                      I am probably having the same issue. But as I am a newbie to Arquillian I can't go much into detail.

                      I just setup the CDI greeting sample with a managed JBoss 7.1.4-SNAPTSHOT (7.1.3.Final adapter) and experiencing a delay after the JBoss start of several seconds. Right after the JBoss start almost 3 seconds without any further log messages and then another 4 seconds before my test method runs.

                       

                      Switching log to TRACE shows something like the following:

                       

                      12:40:02,843 INFO  [org.jboss.as] (Controller Boot Thread) JBAS015874: JBoss AS 7.1.4.Final-SNAPSHOT "Arges" wurde gestartet in 3357ms - 172 von 255 Diensten gestartet (80 Services sind Passiv oder werden bei Bedarf geladen)

                      12:40:05,762 TRACE [org.xnio.nio.selector] (Remoting "tdprg01:MANAGEMENT" read-1) Selected on sun.nio.ch.WindowsSelectorImpl@66229420

                      12:40:05,762 TRACE [org.xnio.nio.selector] (Remoting "tdprg01:MANAGEMENT" read-1) Selected key sun.nio.ch.SelectionKeyImpl@2b7861be for sun.nio.ch.ServerSocketChannelImpl[/127.0.0.1:9999]

                      12:40:05,762 TRACE [org.jboss.modules] (Remoting "tdprg01:MANAGEMENT" read-1) Finding class org.xnio.ChannelListeners from Module "org.jboss.xnio.nio:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:05,762 TRACE [org.jboss.modules] (Remoting "tdprg01:MANAGEMENT" read-1) Finding local class org.xnio.ChannelListeners from Module "org.jboss.xnio:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:05,762 TRACE [org.jboss.modules] (Remoting "tdprg01:MANAGEMENT" read-1) Loading class org.xnio.ChannelListeners locally from Module "org.jboss.xnio:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      ...

                      ...

                      ...

                      12:40:06,106 TRACE [org.jboss.remoting.remote] (Remoting "tdprg01:MANAGEMENT" read-1) Received message window open

                      12:40:06,106 TRACE [org.xnio.channels.framed] (Remoting "tdprg01:MANAGEMENT" read-1) Did not read a length

                      12:40:06,106 TRACE [org.jboss.remoting.remote] (Remoting "tdprg01:MANAGEMENT" read-1) No message ready; returning

                      12:40:06,106 TRACE [org.xnio.nio.selector] (Remoting "tdprg01:MANAGEMENT" read-1) Beginning select on sun.nio.ch.WindowsSelectorImpl@66229420

                       

                      createDeployment

                       

                      12:40:06,481 TRACE [org.xnio.nio.selector] (Remoting "tdprg01:MANAGEMENT" read-1) Selected on sun.nio.ch.WindowsSelectorImpl@66229420

                      12:40:06,481 TRACE [org.xnio.nio.selector] (Remoting "tdprg01:MANAGEMENT" read-1) Selected key sun.nio.ch.SelectionKeyImpl@1efdb84e for java.nio.channels.SocketChannel[connected local=127.0.0.1/127.0.0.1:9999 remote=/127.0.0.1:53878]

                      12:40:06,481 TRACE [org.xnio.listener] (Remoting "tdprg01:MANAGEMENT" read-1) Invoking listener Read listener for org.xnio.channels.FramedMessageChannel around TCP socket channel (NIO) <60212100> on channel TCP socket channel (NIO) <60212100>

                      12:40:06,481 TRACE [org.xnio.listener] (Remoting "tdprg01:MANAGEMENT" read-1) Invoking listener org.jboss.remoting3.remote.RemoteReadListener@588f61e7 on channel org.xnio.channels.FramedMessageChannel around TCP socket channel (NIO) <60212100>

                      12:40:06,481 TRACE [org.xnio.channels.framed] (Remoting "tdprg01:MANAGEMENT" read-1) Copying message from java.nio.HeapByteBuffer[pos=4 lim=388 cap=8196] into java.nio.HeapByteBuffer[pos=0 lim=8192 cap=8192]

                      12:40:06,481 TRACE [org.jboss.remoting.remote] (Remoting "tdprg01:MANAGEMENT" read-1) Received message data

                      ...

                      ...

                      ...

                      12:40:07,059 TRACE [org.jboss.remoting.remote] (Remoting "tdprg01:MANAGEMENT" read-1) Closed inbound message on Channel ID 5e1e3217 (inbound) of Remoting connection 52760f68 to /127.0.0.1:53878

                      12:40:07,059 TRACE [org.xnio.channels.framed] (Remoting "tdprg01:MANAGEMENT" read-1) Did not read a length

                      12:40:07,059 TRACE [org.xnio.nio] (Remoting "tdprg01:MANAGEMENT" read-1) Resume reads on TCP socket channel (NIO) <60212100>

                      12:40:07,059 TRACE [org.xnio.nio] (Remoting "tdprg01:MANAGEMENT" read-1) Setting operations of key sun.nio.ch.SelectionKeyImpl@1efdb84e of java.nio.channels.SocketChannel[connected local=127.0.0.1/127.0.0.1:9999 remote=/127.0.0.1:53878] to 01 (same thread)

                      12:40:07,059 TRACE [org.jboss.remoting.remote] (Remoting "tdprg01:MANAGEMENT" read-1) No message ready; returning

                      12:40:07,059 TRACE [org.xnio.nio.selector] (Remoting "tdprg01:MANAGEMENT" read-1) Beginning select on sun.nio.ch.WindowsSelectorImpl@66229420

                      12:40:07,059 TRACE [org.jboss.as.protocol] (Remoting "tdprg01:MANAGEMENT" task-2) org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1@6626cccc done handling incoming data

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Finding class org.jboss.as.repository.HashUtil from Module "org.jboss.as.deployment-repository:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Finding local class org.jboss.as.repository.HashUtil from Module "org.jboss.as.deployment-repository:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Loading class org.jboss.as.repository.HashUtil locally from Module "org.jboss.as.deployment-repository:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Attempting to define class org.jboss.as.repository.HashUtil in Module "org.jboss.as.deployment-repository:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Defined class org.jboss.as.repository.HashUtil in Module "org.jboss.as.deployment-repository:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Finding class org.jboss.logging.Logger$Level from Module "org.jboss.as.deployment-repository:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Finding local class org.jboss.logging.Logger$Level from Module "org.jboss.logging:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Found previously loaded class org.jboss.logging.Logger$Level from Module "org.jboss.logging:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:07,199 INFO  [org.jboss.as.repository] (management-handler-thread - 2) JBAS014900: Content an Speicherort C:\Develop\jboss71\standalone\data\content\bb\7d4a6b4e727d59bc067ac8e5fc2a73bd85e106\content hinzugef?gt

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Finding class org.jboss.as.protocol.StreamUtils from Module "org.jboss.as.server:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Finding local class org.jboss.as.protocol.StreamUtils from Module "org.jboss.as.protocol:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Found previously loaded class org.jboss.as.protocol.StreamUtils from Module "org.jboss.as.protocol:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Finding class org.jboss.as.server.deployment.DeploymentHandlerUtil$ContentItem from Module "org.jboss.as.server:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      12:40:07,199 TRACE [org.jboss.modules] (management-handler-thread - 2) Finding local class org.jboss.as.server.deployment.DeploymentHandlerUtil$ContentItem from Module "org.jboss.as.server:main" from local module loader @4e22b7dc (roots: C:\Develop\jboss71\modules)

                      ...

                      ...

                      ...

                      12:40:08,651 TRACE [org.jboss.remoting.remote] (Remoting "tdprg01:MANAGEMENT" read-1) Closed inbound message on Channel ID 5e1e3217 (inbound) of Remoting connection 52760f68 to /127.0.0.1:53878

                      12:40:08,651 TRACE [org.jboss.as.protocol] (Remoting "tdprg01:MANAGEMENT" task-4) org.jboss.as.protocol.mgmt.ManagementChannelReceiver$1@6626cccc done handling incoming data

                      12:40:08,651 TRACE [org.xnio.channels.framed] (Remoting "tdprg01:MANAGEMENT" read-1) Did not read a length

                      12:40:08,651 TRACE [org.xnio.nio] (Remoting "tdprg01:MANAGEMENT" read-1) Resume reads on TCP socket channel (NIO) <60212100>

                      12:40:08,651 TRACE [org.xnio.nio] (Remoting "tdprg01:MANAGEMENT" read-1) Setting operations of key sun.nio.ch.SelectionKeyImpl@1efdb84e of java.nio.channels.SocketChannel[connected local=127.0.0.1/127.0.0.1:9999 remote=/127.0.0.1:53878] to 01 (same thread)

                      12:40:08,651 TRACE [org.jboss.remoting.remote] (Remoting "tdprg01:MANAGEMENT" read-1) No message ready; returning

                      12:40:08,651 TRACE [org.xnio.nio.selector] (Remoting "tdprg01:MANAGEMENT" read-1) Beginning select on sun.nio.ch.WindowsSelectorImpl@66229420

                      12:40:08,698 INFO  [org.jboss.as.repository] (management-handler-thread - 3) JBAS014900: Content an Speicherort C:\Develop\jboss71\standalone\data\content\ac\16f9032c4d035e7d58dcd58a5e700501bca372\content hinzugef?gt

                      12:40:08,698 TRACE [org.jboss.modules] (MSC service thread 1-1) Finding class org.jboss.as.arquillian.service.ArquillianService$3 from Module "deployment.arquillian-service:main" from Service Module Loader

                      12:40:08,698 TRACE [org.jboss.modules] (MSC service thread 1-1) Finding local class org.jboss.as.arquillian.service.ArquillianService$3 from Module "deployment.arquillian-service:main" from Service Module Loader

                      12:40:08,698 TRACE [org.jboss.modules] (MSC service thread 1-1) Loading class org.jboss.as.arquillian.service.ArquillianService$3 locally from Module "deployment.arquillian-service:main" from Service Module Loader

                      12:40:08,698 DEBUG [org.jboss.as.controller.management-operation] (management-handler-thread - 3) Entered VERIFY stage; waiting for service container to settle

                      12:40:08,698 TRACE [org.jboss.modules] (MSC service thread 1-1) Attempting to define class org.jboss.as.arquillian.service.ArquillianService$3 in Module "deployment.arquillian-service:main" from Service Module Loader

                      ...

                      ...

                      ...

                      12:40:09,807 TRACE [org.jboss.modules] (pool-3-thread-1) Defined class org.jboss.arquillian.test.impl.EventTestRunnerAdaptor$1 in Module "deployment.arquillian-service:main" from Service Module Loader

                      12:40:09,807 TRACE [org.jboss.modules] (pool-3-thread-1) Finding class org.junit.runners.model.FrameworkMethod$1 from Module "deployment.arquillian-service:main" from Service Module Loader

                      12:40:09,807 TRACE [org.jboss.modules] (pool-3-thread-1) Finding local class org.junit.runners.model.FrameworkMethod$1 from Module "deployment.arquillian-service:main" from Service Module Loader

                      12:40:09,807 TRACE [org.jboss.modules] (pool-3-thread-1) Loading class org.junit.runners.model.FrameworkMethod$1 locally from Module "deployment.arquillian-service:main" from Service Module Loader

                      12:40:09,807 TRACE [org.jboss.modules] (pool-3-thread-1) Attempting to define class org.junit.runners.model.FrameworkMethod$1 in Module "deployment.arquillian-service:main" from Service Module Loader

                      12:40:09,807 TRACE [org.jboss.modules] (pool-3-thread-1) Defined class org.junit.runners.model.FrameworkMethod$1 in Module "deployment.arquillian-service:main" from Service Module Loader

                       

                      Run test

                       

                      12:40:09,807 TRACE [org.jboss.modules] (pool-3-thread-1) Finding class org.junit.Assert from Module "deployment.dc43f2a6-0edb-4510-aea3-191e113b8b41.jar:main" from Service Module Loader

                      12:40:09,807 TRACE [org.jboss.modules] (pool-3-thread-1) Finding local class org.junit.Assert from Module "deployment.arquillian-service:main" from Service Module Loader

                      12:40:09,807 TRACE [org.jboss.modules] (pool-3-thread-1) Found previously loaded class org.junit.Assert from Module "deployment.arquillian-service:main" from Service Module Loader

                      12:40:09,807 INFO  [stdout] (pool-3-thread-1) Hello, Earthling!

                      • 8. Re: Very Slow Deployment: Remote Deployment AS7 / Seam 2.3 App
                        Michal Matloka Newbie

                        Hi

                        Chris Lowe wrote:

                         

                         

                        Would it be possible to control the compression level in shrinkwrap's ZipExporters implementation?  The compression in this use case is unnecessary and slows down the deployment quite a bit.

                        https://issues.jboss.org/browse/SHRINKWRAP-445

                         

                        Chris Lowe wrote:

                         

                         

                        Finally, where can I find the source for the AS7 containers?  The code located at https://github.com/arquillian/arquillian-container-jbossas only seems to support up to JBoss 6.

                         

                        They are in jboss as repos. But separation is in progress https://github.com/aslakknutsen/arquillian-container-jbossas/pull/1 .

                        1 of 1 people found this helpful
                        • 9. Re: Very Slow Deployment: Remote Deployment AS7 / Seam 2.3 App
                          Chris Lowe Apprentice

                          Wow, thank you so much Michal.

                           

                          I'll test your patch over the next day or two and will let you know how I get on.