-
120. Thoughts on filesystem action driven hot deployment
brian.stansberry Apr 6, 2011 10:53 PM (in response to wolfgangknauf)Wolfgang,
Thanks for the question; it's a good one. Yes, if you remove the .failed file the scanner will see the content as eligible for deployment and will therefore try again. To prevent that you'd need to delete the deployment (putting down a .skipdeploy file should prevent it as well, although I haven't tried.)
I'll make a note of that in the README.
-
121. Thoughts on filesystem action driven hot deployment
wolfgangknauf Apr 7, 2011 3:50 PM (in response to brian.stansberry)Thanks for the clarification, Brian.
Another "strange" thing: I have a small app (working fine on AS5), where I get a ".failed" file with this text: "Failed to execute deployment operation in allowed timeout [60]" (I don't know why, will be tracked elsewhere - but it seems to be a good testcase for autodeploy robustness ;-)) . So I delete the ear file once again. The ".failed" file also disappears.
But in "\jboss-7.0.0.Beta3-SNAPSHOT\standalone\configuration\standalone.xml", I still see this:
<deployments>
<deployment name="Stateless.ear" runtime-name="Stateless.ear" sha1="d8aa82f2731236f3ed0b53fca26f35eb0c9c0bc6"/>
</deployments>
Stopping and restarting the server will bring those errors (the errors point to modules in "Stateless.ear"):
21:46:08,937 ERROR [org.jboss.as] (MSC service thread 1-3) JBoss AS 7.0.0.Beta3-SNAPSHOT "TBD" started (with errors) in 4281ms - Started 550 of 584 services (2 services failed or missing dependencies, 32 services are passive or on-demand)
Services missing dependencies:
service jboss.naming.context.java.module.Stateless.StatelessWeb."env/de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelServlet/geometricModel"
service jboss.naming.context.java.module.Stateless.StatelessWeb."env/de.fhw.komponentenarchitekturen.knauf.stateless.GeometricModelServlet/geometricModelLocal"
The sample app can be found here:
http://www.cs.hs-rm.de/~knauf/KomponentenArchitekturen2008/stateless/Stateless.ear
Best regards
Wolfgang
-
122. Thoughts on filesystem action driven hot deployment
wolfgangknauf Apr 7, 2011 3:57 PM (in response to wolfgangknauf)>> To prevent that you'd need to delete the deployment (putting down a .skipdeploy file should prevent it as well, although I haven't tried.)
I gave this a try: yes it works: when deleting the ".failed" file and a ".skipdeploy" file is present, no redeploy happens. Whow, this is confusing - one might need a state diagramm ;-)
Best regards
Wolfgang
-
123. Thoughts on filesystem action driven hot deployment
jason.greene Apr 7, 2011 4:01 PM (in response to wolfgangknauf)Whow, this is confusing - one might need a state diagramm ;-)
Are you volunteering?
-
124. Re: Thoughts on filesystem action driven hot deployment
wolfgangknauf Apr 7, 2011 5:00 PM (in response to jason.greene)I might give it a try, but I would need a lot of help to find all possible situations ;-)
Using ArgoUML and the details I found in the AS7 Readme.txt, here is my first try:
http://www.cs.hs-rm.de/~knauf/private/JBoss7_DeploymentCycle.png
The more I think about it, the more transitions and states appear in the dark (e.g. ".isundeploying", ".undeployed" and ".pending" files are missing) ;-). And this is only a snippet of the the "autodeploy" part...
Any comments are welcome - it might take some days until I find the time to improve it.
-
125. Thoughts on filesystem action driven hot deployment
brian.stansberry Apr 7, 2011 5:32 PM (in response to wolfgangknauf)David Lloyd argued against the .failed files essentially because of the problem you raise. The true representation of the state of the server is in the standalone.xml file, not in these marker files.
The FS scanner is a client to the core server in pretty much the same way that a user using the CLI is and the someone using web console will be. It detects changes on the filesystem, makes requests to the core server management layer and the writes up .failed, .deployed etc based on what it response it gets. Those files represent the client view of the system though; if the server doesn't respond, the FS scanner eventually gives up and marks a failure. But because the server didn't respond the FS scanner doesn't really know the true state on the server side.
The server isn't responding probably due to JBAS-9010, which is being worked. The "Failed to execute deployment operation in allowed timeout [60]" message needs to be beefed up to make it clear that this is an anomalous situation, the scanner doesn't know what happened, and the user needs to investigate and clean up.
https://issues.jboss.org/browse/JBAS-9020 will help with the cleanup issue. Currently we don't track where deployment content comes from, and we treat all content the same, whether it was scanned in from deployments/ or installed into the system via CLI or web console. As a result, following reboot we lose track of whether stuff that was installed by the scanner is no longer present and needs to be undeployed.
-
126. Thoughts on filesystem action driven hot deployment
wolfgangknauf Apr 12, 2011 3:12 PM (in response to brian.stansberry)I updated my state diagram: http://www.cs.hs-rm.de/~knauf/private/JBoss7_DeploymentCycle.png (some detail changes and some UML eye candy ;-))
So, please comment... ;-)
But I have a bunch of questions:
-when a file ".dodeploy" is detected: will the server (no matter what state the app has) redeploy it and afterwards delete this file? E.g. in ".isfailed" state, the app would then be redeployed when the ".isfailed" file is deleted ANd when a ".dodeploy" file is created? The ".dodeploy" file will be deleted when the redeploy starts?
-when is an app added to "standalone.xml"? When deployed successfully AND when deployed with errors?
More question will probably come ;-).
Best regards
-
127. Thoughts on filesystem action driven hot deployment
brian.stansberry Apr 12, 2011 3:40 PM (in response to wolfgangknauf)Wolfgang Knauf wrote:
-when a file ".dodeploy" is detected: will the server (no matter what state the app has) redeploy it and afterwards delete this file? E.g. in ".isfailed" state, the app would then be redeployed when the ".isfailed" file is deleted ANd when a ".dodeploy" file is created? The ".dodeploy" file will be deleted when the redeploy starts?
If auto-deploy is enabled, yes, either removing the .failed file or adding a .dodeploy file will trigger deployment. Putting down a .dodeploy is equivalent to invoking a command; we'll try and carry out the command.
The .dodeploy file is deleted when the operation either succeeds or fails.
-when is an app added to "standalone.xml"? When deployed successfully AND when deployed with errors?
The scanner tells the management layer to do the deployment but to roll it back if the deployment layer reports a failure. So if it the deployment layer reports a failure, the deployment should not appear in standalone.xml..
-
128. Re: Thoughts on filesystem action driven hot deployment
wolfgangknauf Apr 13, 2011 3:23 PM (in response to brian.stansberry)I made some more changes to the diagram to add Brians last comments. Now I am out of questions for the moment.
Jason, you were the one who made me start this stuff,
{quote}Are you volunteering? {quote}
So, I might ping back to you - are you willing to check the output of a volunteer ;-).
And one small issue for the deployment gurus ;-):
I had a "Stateless.ear.failed" file and added a file "Stateless.ear.isdeployed". This resulted in this console exception:
21:13:13,828 ERROR [org.jboss.as.deployment] (DeplooymentScanner-threads - 2) Scan of C:\temp\jboss-7.0.0.Beta3-SNAPSHOT\standalone\deployments threw Exception:
java.lang.NullPointerException
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$DeploymentMarker.access$1000(FileSystemDeploymentService.java:1008)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scanDirectory(FileSystemDeploymentService.java:415)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService.scan(FileSystemDeploymentService.java:288)
at org.jboss.as.server.deployment.scanner.FileSystemDeploymentService$1.run(FileSystemDeploymentService.java:134)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:441) [:1.6.0_24]
at java.util.concurrent.FutureTask$Sync.innerRunAndReset(FutureTask.java:317) [:1.6.0_24]
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:150) [:1.6.0_24]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$101(ScheduledThreadPoolExecutor.java:98) [:1.6.0_24]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.runPeriodic(ScheduledThreadPoolExecutor.java:180) [:1.6.0_24]
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:204) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [:1.6.0_24]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [:1.6.0_24]
at java.lang.Thread.run(Thread.java:662) [:1.6.0_24]
at org.jboss.threads.JBossThread.run(JBossThread.java:122)
Of course this is pure hooliganism, nothing an end user might do, but shouldn't the file system scanner ignore changes to all marker files which are not meant to be created by the end user?
Best regards
Wolfgang
-
129. Re: Thoughts on filesystem action driven hot deployment
brian.stansberry Apr 13, 2011 5:41 PM (in response to wolfgangknauf)Can you file a JIRA? Even better, with a patch. :-)
-
130. Re: Thoughts on filesystem action driven hot deployment
wolfgangknauf Apr 14, 2011 11:50 AM (in response to brian.stansberry) -
131. Re: Thoughts on filesystem action driven hot deployment
wolfgangknauf Apr 18, 2011 2:53 PM (in response to wolfgangknauf)One more question: today's server from GIT made my sample EARs deploy, but there was an error in the web modules. In spite of this error, a "Stateless.ear.deployed" file was created and the ear was added to "standalone.xml".
I would expect to cause the full deployment to fail if any module fails. Or is this misunderstanding of mine ;-)?
And if partial modules can fail, but the full deployment is considered "OK", a status file for each module would be nice, e.g. "Stateless.ear_Stateless.war.failed" or something similar. But this might break all the rest of the deployment concept...
By the way: it seems the app was no longer undeployed when I deleted the ear file on disk? At least the ".deployed" file and the entry in "standalone.xml" was left. And when deleting it, a ".undeployed" file was created and left behind.
Best regards
Wolfgang
-
132. Re: Thoughts on filesystem action driven hot deployment
brian.stansberry Apr 18, 2011 3:13 PM (in response to wolfgangknauf)This is probably due to the work on https://issues.jboss.org/browse/JBAS-9010 that was committed this morning (US time). I'm working on fixing that: https://issues.jboss.org/browse/JBAS-9348