4:54 p.m.
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
--------------------------------------------------------------
Max Rydahl Andersen wrote:
>
> 3) If auto-deploy is available for a type of content, a .skipdeploy marker will
prevent auto-deploy of a particular file.
..particular file or directory, right ?
btw. I really like this "veto" option ;) Much easier to implement from
user/tooling perspective.
Yes, zipped archive or exploded deployment.
> 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.
>
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 ?
Yep.
> 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.
>
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.
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.
>
> 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.
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?)
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&...]