10 Replies Latest reply on Feb 23, 2009 3:48 PM by Marko Strukelj

    Using the profile service to deploy on Windows

    Pete Muir Master

      I'm using JBoss AS 5.0.0.GA and the profile service to deploy:

      DeploymentProgress distribute = deploymentManager.distribute(name, DeploymentPhase.APPLICATION, archive.toURI().toURL(), true);
       distribute.run();
       DeploymentProgress progress = deploymentManager.start(DeploymentPhase.APPLICATION, name);
       progress.run();


      and undeploy:

      deploymentManager.stop(DeploymentPhase.APPLICATION, name).run();
      deploymentManager.undeploy(DeploymentPhase.APPLICATION, name).run();


      The deploy/undeploy is symmetric (I've added log statements, and you get an undeploy for each deploy, and you can also see it in the server log).

      On Mac and Linux, these calls work correctly, and after a run, there are no artifacts left behind in deploy, however on Windows a number are. I can't see any pattern behind those that are left behind. If the undeploy is successful, I get an INFO message from the profile service saying the artifact undeployed, if not, then I don't. Any suggestions?



        • 1. Re: Using the profile service to deploy on Windows
          Emanuel Muckenhuber Master

          Hmm if there are failures during while running you should be able to see those doing this:

           DeploymentStatus status = progress.getDeploymentStatus();
           status.isFailed();
           Throwable failure = status.getFailure();
          


          Can you see that gives you more information why the undeployoment did not work?

          • 2. Re: Using the profile service to deploy on Windows
            Ales Justin Master

            Since it's Windoze, I would suspect it's a deletion problem.
            But I thought we fixed this by having VFS::delete ...

            • 3. Re: Using the profile service to deploy on Windows
              Pete Muir Master

              Here is the exception - sorry about the horrid formatting :-( The initial completed is for the stop() and the failure is for the undeploy...

              INFO [jboss.webbeans.tck.integration.jbossas.ProfileServiceContainersImpl] Deployment status for org.jboss.jsr299.tck.unit.definition.deployment.broken.tooMany.TooManyDeploymentTypesTest.war is COMPLETED
              ERROR [jboss.webbeans.tck.integration.jbossas.ProfileServiceContainersImpl] Error undeploying deployment org.jboss.jsr299.tck.unit.definition.deployment.broken.tooMany.TooManyDeploymentTypesTest.war java.lang.RuntimeException: java.io.IOException: Failed to delete: DelegatingHandler@26316187[path=org.jboss.jsr299.tck.unit.definition.deployment.broken.tooMan
              y.TooManyDeploymentTypesTest.war context=file:/U:/workspace-windows/jboss-5.0.0.GA/server/default/deploy/ real=file:/U:/workspace-windows/jboss-5.0.0.GA/server/default/deploy/org.jboss.jsr299.tck.unit.definition.deployment.broken.tooMany.To
              oManyDeploymentTypesTest.war]
               at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:294)
               at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.undeploy(StreamingDeploymentTarget.java:210)
               at org.jboss.profileservice.management.upload.DeploymentProgressImpl.undeploy(DeploymentProgressImpl.java:312)
               at org.jboss.profileservice.management.upload.DeploymentProgressImpl.run(DeploymentProgressImpl.java:91)
               at org.jboss.webbeans.tck.integration.jbossas.ProfileServiceContainersImpl.undeploy(ProfileServiceContainersImpl.java:106)
               at org.jboss.jsr299.tck.AbstractDeclarativeTest.undeployArtifact(AbstractDeclarativeTest.java:137)
               at org.jboss.jsr299.tck.AbstractDeclarativeTest.afterClass(AbstractDeclarativeTest.java:205)
               at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
               at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
               at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
               at java.lang.reflect.Method.invoke(Method.java:597)
               at org.testng.internal.MethodHelper.invokeMethod(MethodHelper.java:580)
               at org.testng.internal.Invoker.invokeConfigurationMethod(Invoker.java:398)
               at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:145)
               at org.testng.internal.Invoker.invokeConfigurations(Invoker.java:82)
               at org.testng.internal.TestMethodWorker.invokeAfterClassMethods(TestMethodWorker.java:210)
               at org.testng.internal.TestMethodWorker.run(TestMethodWorker.java:113)
               at org.testng.TestRunner.runWorkers(TestRunner.java:712)
               at org.testng.TestRunner.privateRun(TestRunner.java:582)
               at org.testng.TestRunner.run(TestRunner.java:477)
               at org.testng.SuiteRunner.runTest(SuiteRunner.java:324)
               at org.testng.SuiteRunner.runSequentially(SuiteRunner.java:319)
               at org.testng.SuiteRunner.privateRun(SuiteRunner.java:292)
               at org.testng.SuiteRunner.run(SuiteRunner.java:198)
               at org.testng.TestNG.createAndRunSuiteRunners(TestNG.java:821)
               at org.testng.TestNG.runSuitesLocally(TestNG.java:788)
               at org.testng.TestNG.run(TestNG.java:708)
               at org.apache.maven.surefire.testng.TestNGExecutor.run(TestNGExecutor.java:74)
               at org.apache.maven.surefire.testng.TestNGXmlTestSuite.execute(TestNGXmlTestSuite.java:92)
               at org.apache.maven.surefire.Surefire.run(Surefire.java:177)
               at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
               at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
               at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
               at java.lang.reflect.Method.invoke(Method.java:597)
               at org.apache.maven.surefire.booter.SurefireBooter.runSuitesInProcess(SurefireBooter.java:345)
               at org.apache.maven.surefire.booter.SurefireBooter.main(SurefireBooter.java:1009)
              Caused by: java.io.IOException: Failed to delete: DelegatingHandler@26316187[path=org.jboss.jsr299.tck.unit.definition.deployment.broken.tooMany.TooManyDeployme
              ntTypesTest.war context=file:/U:/workspace-windows/jboss-5.0.0.GA/server/default/deploy/ real=file:/U:/workspace-windows/jboss-5.0.0.GA/server/default/deploy/org.jboss.jsr299.tck.unit.definition.deployment.broken.tooMany.TooManyDeploymentTypesTest.war]
               at org.jboss.system.server.profileservice.repository.SerializableDeploymentRepository.removeApplication(SerializableDeploymentRepository.java:1046)
               at org.jboss.system.server.profileservice.repository.SerializableDeploymentRepository.removeDeployment(SerializableDeploymentRepository.java:715)
               at org.jboss.profileservice.management.upload.remoting.DeployHandler.undeploy(DeployHandler.java:269)
               at org.jboss.profileservice.management.upload.remoting.DeployHandler.invoke(DeployHandler.java:157)
               at org.jboss.remoting.ServerInvoker.invoke(ServerInvoker.java:908)
               at org.jboss.remoting.transport.socket.ServerThread.completeInvocation(ServerThread.java:742)
               at org.jboss.remoting.transport.socket.ServerThread.processInvocation(ServerThread.java:695)
               at org.jboss.remoting.transport.socket.ServerThread.dorun(ServerThread.java:522)
               at org.jboss.remoting.transport.socket.ServerThread.run(ServerThread.java:230)
               at org.jboss.remoting.MicroRemoteClientInvoker.invoke(MicroRemoteClientInvoker.java:206)
               at org.jboss.remoting.Client.invoke(Client.java:1708)
               at org.jboss.remoting.Client.invoke(Client.java:612)
               at org.jboss.profileservice.management.upload.remoting.StreamingDeploymentTarget.invoke(StreamingDeploymentTarget.java:286)
               ... 35 more


              • 4. Re: Using the profile service to deploy on Windows
                Emanuel Muckenhuber Master

                In ProfileService we are doing:

                VirtualFile root = vfsDeployment.getRoot();
                if(root.delete() == false)
                 throw new IOException("Failed to delete: " + root);
                


                So this seems to be a VFS issues then - Ales ?

                • 6. Re: Using the profile service to deploy on Windows
                  Pete Muir Master

                  Ok, working on the assumption that Windows locks the file, if the undeploy fails, I've added a loop which every 200ms tries the undeploy again. This seems to work.

                  However, once the deployment has failed, the progress object always returns failed. Is there a way to detect if the subsequent undeploys succeed?

                  DeploymentProgress stopProgress = deploymentManager.stop(DeploymentPhase.APPLICATION, name);
                   stopProgress.run();
                  
                   DeploymentProgress undeployProgress = deploymentManager.undeploy(DeploymentPhase.APPLICATION, name);
                   undeployProgress.run();
                   for (int i = 0; i < 20; i++)
                   {
                   if (!undeployProgress.getDeploymentStatus().isFailed())
                   {
                   return;
                   }
                   else
                   {
                   Thread.sleep(200);
                   undeployProgress = deploymentManager.undeploy(DeploymentPhase.APPLICATION, name);
                   undeployProgress.run();
                   }
                  
                   }
                   if (undeployProgress.getDeploymentStatus().isFailed())
                   {
                   log.error("Undeploy for " + name + " failed!");
                   }


                  Here, even though at i = 0 the app does undeploy, the loop doesn't exit and it logs the error...

                  • 7. Re: Using the profile service to deploy on Windows
                    Pete Muir Master

                    Ok, I spoke too soon. This seems to help somewhat, but not completely. I'm getting a lot more archives removed, but not all of them.

                    • 8. Re: Using the profile service to deploy on Windows
                      Pete Muir Master

                      I've now implemented a workaround, of collecting all failed undeploys, and trying again en masse at the end of the testsuite. This seems to work - I guess the Windows has released it's file lock by then.

                      • 9. Re: Using the profile service to deploy on Windows
                        Ales Justin Master

                        Can we check/monitor for any locks on these files?
                        As VFS already tries something similar - does a few cycles.

                        • 10. Re: Using the profile service to deploy on Windows
                          Marko Strukelj Master

                          I see file: urls in the stack trace from one of the previous posts.

                          All wars, jars, ears should be processed through vfszip urls. This is the only way to make it use our lock release infrastructure.

                          I don't know but maybe file: urls (handled by FileHandler) can leak some file locks ...