jaikiran pai [http://community.jboss.org/people/jaikiran] created the discussion "Re: Thoughts on filesystem action driven hot deployment" To view the discussion, visit: http://community.jboss.org/message/594139#594139 -------------------------------------------------------------- No, I too am in favour of +not+ mandating a marker file to trigger the deployment. And hence that patch with .skipdeploy approach. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/594139#594139] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Dimitris Andreadis [http://community.jboss.org/people/dimitris] created the discussion "Re: Thoughts on filesystem action driven hot deployment" To view the discussion, visit: http://community.jboss.org/message/594143#594143 -------------------------------------------------------------- :-) -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/594143#594143] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Ales Justin [http://community.jboss.org/people/alesj] created the discussion "Re: Thoughts on filesystem action driven hot deployment" To view the discussion, visit: http://community.jboss.org/message/594246#594246 -------------------------------------------------------------- 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) -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/594246#594246] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Brian Stansberry [http://community.jboss.org/people/brian.stansberry] created the discussion "Re: Thoughts on filesystem action driven hot deployment" To view the discussion, visit: http://community.jboss.org/message/594269#594269 -------------------------------------------------------------- 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. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/594269#594269] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Jason Greene [http://community.jboss.org/people/jason.greene] created the discussion "Re: Thoughts on filesystem action driven hot deployment" To view the discussion, visit: http://community.jboss.org/message/594372#594372 -------------------------------------------------------------- We may in the future be able to support it somewhat reliably using FS events, but not without native code (or NIO2 in JDK7): http://jpathwatch.wordpress.com/ http://jpathwatch.wordpress.com/ It would require a well tested algorithm, and it would not have uniform portability. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/594372#594372] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Dimitris Andreadis [http://community.jboss.org/people/dimitris] created the discussion "Re: Thoughts on filesystem action driven hot deployment" To view the discussion, visit: http://community.jboss.org/message/594420#594420 -------------------------------------------------------------- I think Brian meant a .dodeploy marker will be needed if the setting is NONE. If the setting is ZIPPED it will look for a change in any nested zipped archive. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/594420#594420] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Max Rydahl Andersen [http://community.jboss.org/people/maxandersen] created the discussion "Re: Thoughts on filesystem action driven hot deployment" To view the discussion, visit: http://community.jboss.org/message/594557#594557 -------------------------------------------------------------- I go on a small trip and this thread goes wild - sorry for being late to the "party". Great - makes perfect sense. Okey...not sure if it will worth the hassle/CPU-cycles but worth experimenting with. ..particular file or directory, right ? btw. I really like this "veto" option ;) Much easier to implement from user/tooling perspective. Just to be sure I understand this correctly - this means by default AS7 cp -r foo.war AS7/deployments will trigger an deployment of foo.war when it is an archive when the scanner sees the war and it is complete. it will *not* trigger deployment of foo.war when it is a directory. Correct ? It took me a couple of reads of #3 and #4 to get what this meant but this actually makes perfect sense and gives a good balance between preventing bad deployments and still have incremental updates of your exploded content. This basically means the *only* new thing by default is having to do a touch foo.war.dodeploy or the more portable: echo > foo.war.dodeploy for exploded directories. Everything else is just as "before" but better ;) i.e. to make it clean its important that if you detect both a complete foo.war and a foo.war.dodeploy the .dodeploy still gets deleted and goes through the transitions; and that there will be a .deployed file no matter what triggered the deploy. Perfect from first read, but i'm still curious how long that consistency check will take for large projects ? And should there be a maximum of redeployment attempts to avoid the logs for filling/cpu cycles burning ? Maybe have the user made aware of the .dodeploy failing and make it a .deployfailed after some time and thus require a new touch ? (should be fine since if user is doing .dodeploy we should assume that the deployment is actually expected to be complete?) Yes, this works for me :)   I basically get all the goodies I wished for. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/594557#594557] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Brian Stansberry [http://community.jboss.org/people/brian.stansberry] created the discussion "Re: Thoughts on filesystem action driven hot deployment" To view the discussion, visit: http://community.jboss.org/message/594912#594912 -------------------------------------------------------------- Yes, zipped archive or exploded deployment. Yep. Yes. The .deployed file will get laid down either way. If you have auto-deploy enabled and put down a .dodeploy anyway, it will be removed at the end no matter which branch of the logic detects the need to deploy. For a zip that's complete it should be fast. Open a FileChannel and read a few bytes near the very end of the file (in the end of central directory record), then jump to a copy other spots (start of central directory and first local file header) and read a few bytes to validate. If the zip is incomplete it would have to scan back through the last 65K in the file, jumping 4 bytes at a time, so that would be a bit slower. Re: the logs, the way it's coded now it logs once. It won't spam the logs. It doesn't validate the archive if you use .dodeploy. We assume the user means what they say. If someone wants that, I'll look at a patch. I'll look at what it would take to time out and write a .faileddeploy when I get back into this over the next day or so. I think it would be simple. -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/594912#594912] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]

Scott Marlow [http://community.jboss.org/people/smarlow] created the discussion "Re: Thoughts on filesystem action driven hot deployment" To view the discussion, visit: http://community.jboss.org/message/594272#594272 -------------------------------------------------------------- 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).  -------------------------------------------------------------- Reply to this message by going to Community [http://community.jboss.org/message/594272#594272] Start a new discussion in JBoss AS7 Development at Community [http://community.jboss.org/choose-container!input.jspa?contentType=1&...]