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 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.