-
1. Re: Unexpected ear undeployment
nickarls May 24, 2013 7:10 AM (in response to eichmen)Sounds strange, does this happen to other archives? And noone touches the archive after deployment?
-
2. Re: Unexpected ear undeployment
eichmen May 24, 2013 7:35 AM (in response to nickarls)Hi Nicklas,
There isn't more files in deployments folder. I only deploy this ear.
Nobody touches the archive, I'm the only user in the system.
I have read this discussion: https://community.jboss.org/thread/213611 that looks similar.
However it seems that it's not a too many open files because I can't find any log like that. Moreover I have checked the open files with lsof and the number is smaller than max defined in ulimit.
-
3. Re: Unexpected ear undeployment
jaikiran May 24, 2013 7:44 AM (in response to eichmen)Does enabling TRACE level logging of org.jboss.as.server give any hints?
-
4. Re: Unexpected ear undeployment
eichmen May 24, 2013 8:02 AM (in response to jaikiran)I have TRACE level for org.jboss.as and the previous log is:
TRACE [org.jboss.as.server.deployment.scanner] (DeploymentScanner-threads - 1) Scanning directory /usr/local/xxxx/jboss-as-7.1.1.Final/standalone/deployments for deployment content changes
and the nexts to the log of the first post are:
TRACE [org.jboss.as.server.moduleservice] (MSC service thread 1-63) serviceStopping: Controller for service jboss.module.spec.service."deployment.myear.ear.ws-auth.war".main@15714c8d
TRACE [org.jboss.as.server.moduleservice] (MSC service thread 1-62) serviceStopping: Controller for service jboss.module.spec.service."deployment.myear.ear.core.jar".main@61a50976
TRACE [org.jboss.as.server.moduleservice] (MSC service thread 1-57) serviceStopping: Controller for service jboss.module.spec.service."deployment.myear.ear".main@53bfbe41
TRACE [org.jboss.as.server.moduleservice] (MSC service thread 1-21) serviceStopping: Controller for service jboss.module.spec.service."deployment.myear.admin-site.war".main@767de91
-
5. Re: Unexpected ear undeployment
nickarls May 24, 2013 8:07 AM (in response to eichmen)The only "deployment content changes" I come to think of are new/touched/removed deployment archives or marker files.
-
6. Re: Unexpected ear undeployment
eichmen May 24, 2013 8:13 AM (in response to nickarls)Is it possible that Jboss creates a marker file and put it in deployment folder indicating that the ear has to be undeployed due to some stress/blocking situation?
-
7. Re: Unexpected ear undeployment
nickarls May 24, 2013 4:02 PM (in response to eichmen)Unlikely. When things go bad, they go bad quickly ;-)
-
8. Re: Unexpected ear undeployment
jaikiran May 24, 2013 10:43 PM (in response to eichmen)1 of 1 people found this helpfulAre you sure the deployment had fully completed? I mean, perhaps someone has changed your standalone.xml configuration to increase the deployment timeout to 10 minutes and the application perhaps is taking that long to get deployed and when it hits the 10 minute mark, the server notices it hasn't yet deployed and triggers a undeploy? I would have expected a different log message though, but I can't guess anything else at this point. The other thing to check would have been any changes to the files within the deployment which might trigger a redeployment, but just undeploying without a subsequent deploy seems strange.
-
9. Re: Unexpected ear undeployment
eichmen May 27, 2013 3:35 AM (in response to jaikiran)Hi,
Thanks for your answers.
I think that deployment had fully completed because Jboss shows the following log:
INFO [org.jboss.as.server] (DeploymentScanner-threads - 2) JBAS018559: Deployed "myear.ear".
This weekend I have disabled the jboss scanner and the application has worked continuously until now (it's still working now). Does that make any sense?
-
10. Re: Unexpected ear undeployment
jaikiran May 27, 2013 4:02 AM (in response to eichmen)M. Perez wrote:
This weekend I have disabled the jboss scanner and the application has worked continuously until now (it's still working now). Does that make any sense?
In that case, I'm suspecting that some file within that deployment is changed (timestamp) which I think is triggering a redeployment.
-
11. Re: Unexpected ear undeployment
nickarls May 27, 2013 6:54 AM (in response to eichmen)1 of 1 people found this helpfulIf you are *really* interested, you could start up the AS in debug mode, place a breakpoint in the source at the deployment scanner where it picks up changes and see what is the triggering factor...
-
12. Re: Unexpected ear undeployment
ctomc May 27, 2013 5:10 PM (in response to jaikiran)There is also one other explaination, as this same thing happened to us on lightning...
What could happen is that if server's disk is bit slow while deployment scanner is scanning for changes in deployment it might throw some IO exception.
In some cases that can result in "undeploy" action by deployment scanner. This exact scenario is rare and hard to reproduce, but i can tell from expirence that this is was the case for one of our servers...
In any case deployment scanner is not recommented to be used in production as it can considrably decrese perforamnce of server.
--
tomaz -
13. Re: Unexpected ear undeployment
eichmen May 28, 2013 2:24 AM (in response to ctomc)Thanks Tomaz,
Our server's disks are fast enough in my opinion.
I'm going to test the system behaviour disabling scanner and loading the ear via Jboss Management Console.
-
14. Re: Unexpected ear undeployment
nickarls May 28, 2013 2:30 AM (in response to ctomc)Next time you're bored, you could write a DB-backed deployment scanner, you could just insert the deployment into a blob and commit(); ;-)