] created the
discussion
"Re: Thoughts on filesystem action driven hot deployment"
To view the discussion, visit:
> Brian Stansberry wrote:
>
> Thanks for the input. I was off yesterday; hence the slow reply.
>
> > Max Andersen wrote:
> >
> > Local and remote deployment are different things, but both have usecases for
hotdeployment functionallity - i.e. me updating a html page shouldn't require a full
restart of an app, even if running remotely on an EC2 server for my testing.
> >
> I'm interpreting this as a request for a remotable API to allow users to 1)
upload exploded deployments and 2) upload individual files to change the contents of those
deployments. If that's correct, can you file a JIRA, as that isn't on any
roadmap.
>
>
http://community.jboss.org/thread/154922 http://community.jboss.org/thread/154922 list
the discussions done at JBoss World and previous about this topic.
If you want me to create a jira for it I will - which component in JBAS should it be ?
> > I don't understand why you have to *remove* the deployed files - if they
aren't locked by appserver then please keep them there otherwise tooling have to
constantly copy all content to the location (this is not a problem in toy samples, but
take a Seam EAR, that is over 20MB of data....that takes time, CPU and disk IO on even the
fastests systems - if I touch a html file - tools should not need to copy all again)
> For exploded content the intent is to leave the original file there. The assumption
is the reason people use an exploded deployment is they want to be able to manipulate its
contents, so deleting it would be non-sensical. :)
Yup - btw. I assume you copy the content to avoid locks or will the content actually be
locked as it was the case for <7 ?
(i.e. jar's were getting locked on windows 7)
> > For Zipped archives we still have to copy all so that is less of an issue -
but why not keep the file there so users can actually see what got deployed and they can
adjust content as they need ? (I really find this "delete what got
deployed"-approach weird..I don't understand the reasoning)
> >
> What do you mean "they can adjust content as they need?" Only thing I can
think of is to replace the zip with another version.
In some cases you as a user don't actually have the "original". I.e. when
using tools that incrementally keeps the jar uptodate the user just have the
"source" files not the actual jar. Meaning if he spots an error somewhere and
want to reduce the possible error causes he stops the tooling and go look at the actual
deployed thing. Pre AS 7 (or any other server I've worked with) you can simply go and
unzip -l the content and from there see what actually got deployed and redeploy again with
changes if you need to (without having to involve extra layers of tooling or
maintanence).
> I'm OK with leaving the original deployment around. Jaikiran commented way back
that removing it forces the user to keep a copy of it around somewhere else.
>
>
>
>
Exactly.
> The logic for removing it is once the scanner has picked up foo.war and deployed it,
the foo.war.deployed file is what matters. Deleting that file is what triggers undeploy.
Deleting foo.war itself does nothing., and leaving the file there leads people to believe
that deleting it means something.
>
> I know that's a bit inconsistent though, since copying in a new version of
foo.war does trigger a deployment action.
>
> If we're going to leave the original file around, for zipped files IMO we should
do away with the marker files, and use them solely for exploded deployments, where they
have a clear purpose. If the zipped files are left around, the only thing the marker files
provide is an indication that the content was actually deployed. There are other ways to
see that; and by itself that's not justification for the confusion of having two files
around.
I agree - if the file stays around the marker file has no real importance.
Well, maybe for consistency and actually knowing the file got deployed without having to
scan logs ?
Or is there other/better ways to get this info now ?
> > How are users to know where the actual deployment is happening from ?
Suggestion: put a deploy.location=/var/tmp/blahbla/foo.war into the marker file - simply
for ease of debugging/transparency.
> I've been tempted to do that. Haven't because 1) it forms a semi-contract
that I'm not sure we should commit ourselves to. 2) It also encourages poking around
in places users aren't meant to go poking. 3) It also forces the deployment content
repository to expose internal implementation details to the deployment scanner service,
which isn't the end of the world but isn't nice either.
>
> There is INFO level logging of where the deployment content is stored (which shoots
my #2 above). :-)
>
I keep hearing this "by exposing the actual deployment location there is a
semi-contract"-excuse and I just don't buy it.
The deployment is going to be *somewhere* wether that is on the filesystem or in-memory
then telling the user where it is being 'read' from is never a bad information to
have.
And as you said - it gets logged anyway (for a reason I assume ? :)
> > Why have markers both at toplevel /foo.war.deployed and
foo.war/META-INF/jboss-deploy - why not just have them as foo.war.deploy (request
deployment of foo.war) and foo.war.deployed (marker for foo.war have been deployed) ? More
consistent IMO.
> Fine with me.
At submodule deployments it might make sense to have other markers at a different
"Depth" but when its the "same" thing you trigger a redeploy of the
marker should be the same.
> > Another issue is though how is all of this going to work for updates that
should not trigger a full restart of a module ? i.e. updating html/xhtml pages does not
force a restart of a module which causes current sessions to be destroyed ?
> Good question. We'd been talking in terms of having the exploded content in
deployments/ directly mounted, i.e. being directly used as the deployment content. The
marker files would serve to trigger deploy/undeploy/redeploy. Once the content was
deployed, changes in the content, e.g. a new deployments/foo.war/index.jsp, would be
immediately visible.
Ok - sounds good; but I guess for .jar's you will copy-on-read to avoid classloader
filesystem locking or will we still have the same old problem ?
> The downside to that is multiple changes can't be made as an atomic unit, with
no requests seeing only some of the changes. But I don't think that's a critical
use case. Devs doing testing will deploy content, make some requests, update some files in
the deployment, make some requests, etc. They're not making requests in the middle of
copying in changed files.
This is actually a critical use case. Today we use jmx calls to tell AS to *not* scan
folders while we are copying files over and then continue when we are done. If we
didn't do that you would see *alot* more failure deployments.
i.e. users updating a jar or set of jars - that copy operation will actually take some
ms's or even seconds for large jars and without disabling the scanner we see alot more
partial deployments.
This can happen both on the initial creation of the foo.war or during editing/changes.
I think it would be great have a marker file to prevent deployment - i.e.
foo.war.nodeploy would make the scanner skip checking foo.war. Then the tool or user can
remove it when he wants it in play again.
--------------------------------------------------------------
Reply to this message by going to Community
[