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
      • 90. Re: Thoughts on filesystem action driven hot deployment
        jaikiran

        Stan Silvert wrote:

         


         

        Nothing happens.  Decide it's time to look at the README.  (BTW, the README says "/deployment" but the dir name is plural "/deployments")

        https://issues.jboss.org/browse/JBAS-9048

         

         

        Stan Silvert wrote:

         


        1) Create a "dodeploy" file.

        2) Start AS

         

        Nothing happens.  I notice that my dodeploy file name is misspelled.  The WAR name is a little long and complicated, so that's not surprising.  But I'm annoyed at the fact that I had to type it and now I have to fix it.

         

        1) Fix the file name

        2) Start AS

         

        Nothing happens except that I get this warning:

        09:08:26,174 WARN  [org.jboss.as.deployment] (pool-6-thread-1) Deployment of 'C:
        \jboss-7.0.0.Beta1\standalone\deployments\mojarra2.0-notbundled.war.dodeploy' re
        quested, but the deployment is not present

         

        But I know the deployment is there!  Maybe I should touch the dodeploy.  I can't do that from Explorer so I have to open a command prompt.  There is no "touch" command on Windows, but luckily I have Cygwin in my path for just such occasions.  Woops!  I can't touch what isn't there.  My dodeploy file is gone!!  Where did it go?

         

        Let's take the README a more literally.  Instead of creating a dodeploy file and starting the server, let's try starting the server and actually issuing the touch command from the command prompt.

         

        1) Start AS

        2) cd to standalone/deployments

        3) touch my-long-funky-war-name.war.dodeploy

         

        It finally deploys!!

         

        I tried reproducing this on my Ubuntu system, but couldn't. Probably Windows specific? Irrespective of what approach we end up taking for file system deployments, this probably qualifies as a bug in 7.0 Beta1 and so I created a JIRA https://issues.jboss.org/browse/JBAS-9050

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

          AIUI, the bug is Stan mistyped the file name. :-) The question is whether deleting the wrnog-spelling.dodeploy is the right thing to do. The scanner deletes extraneous marker files as a matter of housekeeping. That behavior could be removed, but I'd argue that in this case, it's disconcerting but somewhat helpful. The file is gone, forcing the user to try again and maybe get it right.

          • 92. Re: Thoughts on filesystem action driven hot deployment
            dimitris

            Is it just me that thinks you shouldn't need a marker file to initiate a deployment? A good design minimises the possibility of people screwing up by mistake.

            • 93. Re: Thoughts on filesystem action driven hot deployment
              jaikiran

              Dimitris Andreadis wrote:

               

              Is it just me that thinks you shouldn't need a marker file to initiate a deployment?

              No, I too am in favour of not mandating a marker file to trigger the deployment. And hence that patch with .skipdeploy approach.

              • 94. Re: Thoughts on filesystem action driven hot deployment
                dmlloyd

                Next person to complain about marker files without a patch is buying the beer at JBW

                • 95. Re: Thoughts on filesystem action driven hot deployment
                  dimitris

                  :-)

                  • 96. Re: Thoughts on filesystem action driven hot deployment
                    ssilvert

                    Brian Stansberry wrote:

                     

                    AIUI, the bug is Stan mistyped the file name. :-) The question is whether deleting the wrnog-spelling.dodeploy is the right thing to do. The scanner deletes extraneous marker files as a matter of housekeeping. That behavior could be removed, but I'd argue that in this case, it's disconcerting but somewhat helpful. The file is gone, forcing the user to try again and maybe get it right.

                     

                    At the risk of owing David a beer (you'll have to come to ATL to get it!), let me point something out.  If I mistype the long file name I want to edit it, not type the whole thing in again.  I can't edit the file name if it is deleted.  If I did this from the command line I could just scroll through my previous commands, but from Explorer I'm screwed.

                     

                    Stan

                    • 97. Re: Thoughts on filesystem action driven hot deployment
                      jason.greene

                      Stan,

                       

                      Are you running a current version? The console log tells you the file you need to create. If it's fresh boot the message is a little too early. We can look at ways to make it more noticeable.

                      • 98. Re: Thoughts on filesystem action driven hot deployment
                        jason.greene

                        Let me make this perfectly clear. Whether or not there is a patch does not change the fact that I want non broken behavior by default. In other words I will reject any patch that does not attempt to address the technical issues I have laid out repeatedly. Yes usability matters, but so does software that doesn't look like a shoddy peice of junk. When someone  intermittently gets 30 stack traces when they drop a big exploded deployment, they think wow jboss is buggy and they are right.

                         

                        There are ways to address this Issue. I have already mentioned one that solves it for zip style deployments. However, you guys are sitting around with your fingers in your ears yelling NO MARKERS.

                        • 99. Re: Thoughts on filesystem action driven hot deployment
                          alesj
                          When someone  intermittently gets 30 stack traces when they drop a big exploded deployment, they think wow jboss is buggy and they are right.

                           

                          However, you guys are sitting around with your fingers in your ears yelling NO MARKERS.

                          How is "big deployment" + "patch" + ".skip" equal to NO MARKERS?

                           

                          That big deployment would only get picked up and fully deployed once .skip is removed / deleted.

                          Which is probably pretty much the same as adding .dodeploy.

                          (ok, technically it's the opposite, but the end result would be the same -- no non-atomic deployments)

                          • 100. Re: Thoughts on filesystem action driven hot deployment
                            jason.greene

                            Because the whole point of the skip patch is to support no marker deployments at the cost of adding an extra step to the "correct" workflow. The problem is the user will not know they need the skip markers. They will just see non-deterministic behavior and go on a wild goose chase.

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

                              Here's what I'm doing. Following uses the term "auto-deploy" to refer to the scanner deciding to deploy without being told to via a .dodeploy marker.

                               

                              1) I'm adding the zip scanning Jason mentioned to detect whether the zip is complete. This is the basis for reliable auto-deploy of zipped content.

                               

                              2) Reliable auto-deploy of exploded content is not possible. As a safety aid I will use the scanning code from 1) to check any nested jars, but that doesn't make it reliable.

                               

                              3) If auto-deploy is available for a type of content, a .skipdeploy marker will prevent auto-deploy of a particular file.

                               

                              3) I'm going to add an "auto-deploy" flag to the deployment-scanner element, with legal values "ALL", "ZIPPED", "NONE". Flag controls what types of content auto-deploy behavior is enabled for. Per Jason's statement above, default is "ZIPPED", as "ALL" cannot be made reliable. Configuring "ALL" will result in a WARN message in the server log.

                               

                              4) For auto-deploy of exploded content, there will be no deployment descriptor file timestamp check as the means of detecting the need to redeploy, as in EE 6 there is no universal requirement for deployment descriptors. And checking the directory timestamp is not valid as it's easy to change content without triggering a change in the directory timestamp. So, with auto-deploy if any file in the deployment changes, the deployment gets redeployed. People who want to change content without triggering redeploy are going to have to use marker files; either leave auto-deploy disabled and use .dodeploy, or enable auto-deploy and use .skipdeploy.

                               

                              5) If a scan tries to use auto-deploy for a file and detects incomplete content, the scan will be aborted (i.e. it will be as if no changes were detected.) The next time the scanner runs, it will check again.

                               

                              AFAICT, this is essentially completing what was discussed in Antwerp and detailed a few pages back by Max. Difference is auto-deploy of exploded content will not be default behavior.

                              • 102. Thoughts on filesystem action driven hot deployment
                                smarlow

                                Most of the problems that I ran into with AS 4 farm deployment were usually with the file system not allowing the user to express the actions that they really want performed.  My workaround was to tell users to avoid ambigous file system operations (don't delete a deployment on a stopped AS 4 cluster node).

                                 

                                The tags are an excellent work around (they allow additional actions to be expressed by the user that we couldn't do in AS4 land).  Even, better would be to eliminate scanning of the file systems for deployment and instead allow external tooling to handle the same functionality.  This would be in the form of an external file system scanner that deploys/undeploys by interacting with the AS admin api.  This could expand into other kinds of scanners, well beyond the file system (e.g. deploying applications as they are checked into git or perhaps draggedNDropped onto a webdav server).

                                 

                                The flow would go something like:

                                 

                                1.  Start the AS

                                2.  Launch the "old school" external file system scanner, passing AS server connectivity options.  It starts scanning for deployments.

                                3.  If a current deployment is deleted from the "old school" folder, it is undeployed.  If a deployment is copied in, it is deployed.

                                 

                                Perhaps you like the tagged approach, so you instead launch the "tagged" external file system scanner, which works mostly like the current AS7 file system scanner.

                                 

                                Maybe later, your boss wants you to track every application that gets deployed.  So, you launch the "git" external scanner and that tracks history for you. 

                                 

                                I'm not sure if this helps for AS 7.0, but if this approach is desireable, we could design for it and maybe build enough to satisfy the tagged and non-tagged approaches (we only need the admin api and to create the external old school file system scanner). 

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

                                  Stan Silvert wrote:

                                   

                                  Brian Stansberry wrote:

                                   

                                  AIUI, the bug is Stan mistyped the file name. :-) The question is whether deleting the wrnog-spelling.dodeploy is the right thing to do. The scanner deletes extraneous marker files as a matter of housekeeping. That behavior could be removed, but I'd argue that in this case, it's disconcerting but somewhat helpful. The file is gone, forcing the user to try again and maybe get it right.

                                   

                                  At the risk of owing David a beer (you'll have to come to ATL to get it!), let me point something out.  If I mistype the long file name I want to edit it, not type the whole thing in again.  I can't edit the file name if it is deleted.  If I did this from the command line I could just scroll through my previous commands, but from Explorer I'm screwed.

                                   

                                  Stan

                                   

                                  Looking at the code I don't see how leaving around marker files that don't match content causes any difficulties in the code, so I'll remove the bit that deletes them.

                                  • 104. Re: Thoughts on filesystem action driven hot deployment
                                    smarlow

                                    I meant marker, not tag... 

                                    1 5 6 7 8 9 Previous Next