1 5 6 7 8 9 Previous Next 132 Replies Latest reply on Apr 18, 2011 3:13 PM by brian.stansberry Go to original post
      • 120. Thoughts on filesystem action driven hot deployment
        brian.stansberry

        Wolfgang,

         

        Thanks for the question; it's a good one. Yes, if you remove the .failed file the scanner will see the content as eligible for deployment and will therefore try again. To prevent that you'd need to delete the deployment (putting down a .skipdeploy file should prevent it as well, although I haven't tried.)

         

        I'll make a note of that in the README.

        • 121. Thoughts on filesystem action driven hot deployment
          wolfgangknauf

          Thanks for the clarification, Brian.

           

          Another "strange" thing: I have a small app (working fine on AS5), where I get a ".failed" file with this text: "Failed to execute deployment operation in allowed timeout [60]" (I don't know why, will be tracked elsewhere - but it seems to be a good testcase for autodeploy robustness ;-)) . So I delete the ear file once again. The ".failed" file also disappears.

           

          But in "\jboss-7.0.0.Beta3-SNAPSHOT\standalone\configuration\standalone.xml", I still see this:

           

              <deployments>

                  <deployment name="Stateless.ear" runtime-name="Stateless.ear" sha1="d8aa82f2731236f3ed0b53fca26f35eb0c9c0bc6"/>

              </deployments>

           

          Stopping and restarting the server will bring those errors (the errors point to modules in "Stateless.ear"):

           

          21:46:08,937 ERROR [org.jboss.as] (MSC service thread 1-3) JBoss AS 7.0.0.Beta3-SNAPSHOT "TBD" started (with errors) in 4281ms - Started 550 of 584 services (2 services failed or missing dependencies, 32 services are passive or on-demand)

              Services missing dependencies:

                  service jboss.naming.context.java.module.Stateless.StatelessWeb."env/de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelServlet/geometricModel"

                  service jboss.naming.context.java.module.Stateless.StatelessWeb."env/de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelServlet/geometricModelLocal"

           

          The sample app can be found here:

          http://www.cs.hs-rm.de/~knauf/KomponentenArchitekturen2008/stateless/Stateless.ear

           

          Best regards

           

          Wolfgang

          • 122. Thoughts on filesystem action driven hot deployment
            wolfgangknauf

            >> To prevent that you'd need to delete the deployment (putting down a .skipdeploy file should prevent it as well, although I haven't tried.)

             

            I gave this a try: yes it works: when deleting the ".failed" file and a ".skipdeploy" file is present, no redeploy happens. Whow, this is confusing - one might need a state diagramm ;-)

             

            Best regards

             

            Wolfgang

            • 123. Thoughts on filesystem action driven hot deployment
              jason.greene

              Whow, this is confusing - one might need a state diagramm ;-)

              Are you volunteering?

              • 124. Re: Thoughts on filesystem action driven hot deployment
                wolfgangknauf

                I might give it a try, but I would need a lot of help to find all possible situations ;-)

                 

                Using ArgoUML and the details I found in the AS7 Readme.txt, here is my first try:

                 

                http://www.cs.hs-rm.de/~knauf/private/JBoss7_DeploymentCycle.png

                 

                The more I think about it, the more transitions and states appear in the dark  (e.g. ".isundeploying", ".undeployed" and ".pending" files are missing) ;-). And this is only a snippet of the the "autodeploy" part...

                 

                Any comments are welcome - it might take some days until I find the time to improve it.

                • 125. Thoughts on filesystem action driven hot deployment
                  brian.stansberry

                  David Lloyd argued against the .failed files essentially because of the problem you raise. The true representation of the state of the server is in the standalone.xml file, not in these marker files.

                   

                  The FS scanner is a client to the core server in pretty much the same way that a user using the CLI is and the someone using web console will be. It detects changes on the filesystem, makes requests to the core server management layer and the writes up .failed, .deployed etc based on what it response it gets. Those files represent the client view of the system though; if the server doesn't respond, the FS scanner eventually gives up and marks a failure. But because the server didn't respond the FS scanner doesn't really know the true state on the server side.

                   

                  The server isn't responding probably due to JBAS-9010, which is being worked. The "Failed to execute deployment operation in allowed timeout [60]" message needs to be beefed up to make it clear that this is an anomalous situation, the scanner doesn't know what happened, and the user needs to investigate and clean up.

                   

                  https://issues.jboss.org/browse/JBAS-9020 will help with the cleanup issue. Currently we don't track where deployment content comes from, and we treat all content the same, whether it was scanned in from deployments/ or installed into the system via CLI or web console. As a result, following reboot we lose track of whether stuff that was installed by the scanner is no longer present and needs to be undeployed.

                  • 126. Thoughts on filesystem action driven hot deployment
                    wolfgangknauf

                    I updated my state diagram: http://www.cs.hs-rm.de/~knauf/private/JBoss7_DeploymentCycle.png (some detail changes and some UML eye candy ;-))

                    So, please comment... ;-)

                     

                    But I have a bunch of questions:

                    -when a file ".dodeploy" is detected: will the server (no matter what state the app has) redeploy it and afterwards delete this file? E.g. in ".isfailed" state, the app would then be redeployed when the ".isfailed" file is deleted ANd when a ".dodeploy" file is created? The ".dodeploy" file will be deleted when the redeploy starts?

                    -when is an app added to "standalone.xml"? When deployed successfully AND when deployed with errors?

                    More question will probably come ;-).

                     

                    Best regards

                    • 127. Thoughts on filesystem action driven hot deployment
                      brian.stansberry

                      Wolfgang Knauf wrote:

                      -when a file ".dodeploy" is detected: will the server (no matter what state the app has) redeploy it and afterwards delete this file? E.g. in ".isfailed" state, the app would then be redeployed when the ".isfailed" file is deleted ANd when a ".dodeploy" file is created? The ".dodeploy" file will be deleted when the redeploy starts?

                       

                      If auto-deploy is enabled, yes, either removing the .failed file or adding a .dodeploy file will trigger deployment. Putting down a .dodeploy is equivalent to invoking a command; we'll try and carry out the command.

                       

                      The .dodeploy file is deleted when the operation either succeeds or fails.

                      -when is an app added to "standalone.xml"? When deployed successfully AND when deployed with errors?

                       

                      The scanner tells the management layer to do the deployment but to roll it back if the deployment layer reports a failure. So if it the deployment layer reports a failure, the deployment should not appear in standalone.xml..

                      • 128. Re: Thoughts on filesystem action driven hot deployment
                        wolfgangknauf

                        I made some more changes to the diagram to add Brians last comments. Now I am out of questions for the moment.

                         

                        Jason, you were the one who made me start this stuff,

                         

                        {quote}Are you volunteering? {quote}

                         

                        So, I might ping back to you - are you willing to check the output of a volunteer ;-).

                         

                        And one small issue for the deployment gurus ;-):

                        I had a "Stateless.ear.failed" file and added a file "Stateless.ear.isdeployed". This resulted in this console exception:

                         

                        21:13:13,828 ERROR [org.jboss.as.deployment] (DeplooymentScanner-threads - 2) Scan of C:\temp\jboss-7.0.0.Beta3-SNAPSHOT\standalone\deployments threw Exception:

                        java.lang.NullPointerException

                                at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentMarker.access$1000(FileSystemDeploymentService.java:1008)

                                at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scanDirectory(FileSystemDeploymentService.java:415)

                                at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:288)

                                at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$1.run(FileSystemDeploymentService.java:134)

                                at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_24]

                                at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_24]

                                at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_24]

                                at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_24]

                                at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [:1.6.0_24]

                                at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [:1.6.0_24]

                                at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]

                                at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]

                                at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]

                                at org.jboss.threads.JBossThread.run(JBossThread.java:122)

                         

                        Of course this is pure hooliganism, nothing an end user might do, but shouldn't the file system scanner ignore changes to all marker files which are not meant to be created by the end user?

                         

                        Best regards

                         

                        Wolfgang

                        • 129. Re: Thoughts on filesystem action driven hot deployment
                          brian.stansberry

                          Can you file a JIRA?  Even better, with a patch. :-)

                          • 130. Re: Thoughts on filesystem action driven hot deployment
                            wolfgangknauf

                            JIRA filed: https://issues.jboss.org/browse/JBAS-9322

                             

                            Sorry, no patches possible by me ;-)

                            • 131. Re: Thoughts on filesystem action driven hot deployment
                              wolfgangknauf

                              One more question: today's server from GIT made my sample EARs deploy, but there was an error in the web modules. In spite of this error, a "Stateless.ear.deployed" file was created and the ear was added to "standalone.xml".

                               

                              I would expect to cause the full deployment to fail if any module fails. Or is this misunderstanding of mine ;-)?

                               

                              And if partial modules can fail, but the full deployment is considered "OK", a status file for each module would be nice, e.g. "Stateless.ear_Stateless.war.failed" or something similar. But this might break all the rest of the deployment concept...

                               

                              By the way: it seems the app was no longer undeployed when I deleted the ear file on disk? At least the ".deployed" file and the entry in "standalone.xml" was left. And when deleting it, a ".undeployed" file was created and left behind.

                               

                              Best regards

                               

                              Wolfgang

                              • 132. Re: Thoughts on filesystem action driven hot deployment
                                brian.stansberry

                                This is probably due to the work on https://issues.jboss.org/browse/JBAS-9010 that was committed this morning (US time).  I'm working on fixing that: https://issues.jboss.org/browse/JBAS-9348

                                1 5 6 7 8 9 Previous Next