[JBoss JIRA] (AS7-5749) Reading deployment resource with missing dependencies leads to exception
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-5749?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar commented on AS7-5749:
----------------------------------
I cannot reproduce this.
{noformat}
as I get JBAS014808: Child resource '"deployment" => "stores-web.war"' not found
{noformat}
for deployment that has missing dependencies like this
given that you are using quite old version (2 months+) can you take newer nightly build and try with it?
> Reading deployment resource with missing dependencies leads to exception
> ------------------------------------------------------------------------
>
> Key: AS7-5749
> URL: https://issues.jboss.org/browse/AS7-5749
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Tomaz Cerar
> Fix For: 7.2.0.Alpha1
>
>
> Reading from a deployment with missing dependencies leads to an IllegalArg exception:
> {noformat}
> 10:05:04,971 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("read-attribute") failed - address: ([("deployment" => "jboss-as-login.war")]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:248) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.server.deployment.DeploymentStatusHandler.execute(DeploymentStatusHandler.java:50)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:414) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:296) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:216) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:482) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:414) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:296) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:216) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:135) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:111) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_35]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_35]
> at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_35]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
> {noformat}
> The management layer response isn't helpful in this case:
> {noformat}
> [INFO] {
> [INFO] "outcome" => "failed",
> [INFO] "rolled-back" => true
> [INFO] }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6031) deploy directories not cleaned up
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/AS7-6031?page=com.atlassian.jira.plugin.s... ]
Bartosz Baranowski edited comment on AS7-6031 at 1/9/13 10:00 AM:
------------------------------------------------------------------
Well in that case the startup will take longer, as well as shutdown when JVM shutdown hook will do the "deleteOnExit". If the server goes down properly, there will be no penalty during startup.
But.. for sake of beeing thorough I will modify apps so the contain different types of files(one big, few smallers) so each deployment has more than 30MBs
was (Author: baranowb):
Well in that case the startup will take longer, as well as shutdown when JVM shutdown hook will do the "deleteOnExit". If the server goes down properly, there will be no penalty.
But.. for sake of beeing thorough I will modify apps so the contain different types of files(one big, few smallers) so each deployment has more than 30MBs
> deploy directories not cleaned up
> ---------------------------------
>
> Key: AS7-6031
> URL: https://issues.jboss.org/browse/AS7-6031
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Shaun Appleton
> Assignee: Bartosz Baranowski
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5749) Reading deployment resource with missing dependencies leads to exception
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/AS7-5749?page=com.atlassian.jira.plugin.s... ]
Tomaz Cerar reassigned AS7-5749:
--------------------------------
Assignee: Tomaz Cerar (was: Brian Stansberry)
> Reading deployment resource with missing dependencies leads to exception
> ------------------------------------------------------------------------
>
> Key: AS7-5749
> URL: https://issues.jboss.org/browse/AS7-5749
> Project: Application Server 7
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Braun
> Assignee: Tomaz Cerar
> Fix For: 7.2.0.Alpha1
>
>
> Reading from a deployment with missing dependencies leads to an IllegalArg exception:
> {noformat}
> 10:05:04,971 ERROR [org.jboss.as.controller.management-operation] (management-handler-thread - 1) JBAS014612: Operation ("read-attribute") failed - address: ([("deployment" => "jboss-as-login.war")]): java.lang.IllegalArgumentException
> at org.jboss.dmr.ModelValue.asBoolean(ModelValue.java:66) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.dmr.ModelNode.asBoolean(ModelNode.java:248) [jboss-dmr-1.1.1.Final.jar:1.1.1.Final]
> at org.jboss.as.server.deployment.DeploymentStatusHandler.execute(DeploymentStatusHandler.java:50)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:414) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:296) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:216) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl$DefaultPrepareStepHandler.execute(ModelControllerImpl.java:482) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:414) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:296) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStep(AbstractOperationContext.java:216) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:135) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:111) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler.doExecute(ModelControllerClientOperationHandler.java:139) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.controller.remote.ModelControllerClientOperationHandler$ExecuteRequestHandler$1.execute(ModelControllerClientOperationHandler.java:108) [jboss-as-controller-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [jboss-as-protocol-7.2.0.Alpha1-SNAPSHOT.jar:7.2.0.Alpha1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor$Worker.runTask(ThreadPoolExecutor.java:886) [classes.jar:1.6.0_35]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:908) [classes.jar:1.6.0_35]
> at java.lang.Thread.run(Thread.java:680) [classes.jar:1.6.0_35]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.0.0.GA.jar:2.0.0.GA]
> {noformat}
> The management layer response isn't helpful in this case:
> {noformat}
> [INFO] {
> [INFO] "outcome" => "failed",
> [INFO] "rolled-back" => true
> [INFO] }
> {noformat}
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-6031) deploy directories not cleaned up
by Bartosz Baranowski (JIRA)
[ https://issues.jboss.org/browse/AS7-6031?page=com.atlassian.jira.plugin.s... ]
Bartosz Baranowski commented on AS7-6031:
-----------------------------------------
Well in that case the startup will take longer, as well as shutdown when JVM shutdown hook will do the "deleteOnExit". If the server goes down properly, there will be no penalty.
But.. for sake of beeing thorough I will modify apps so the contain different types of files(one big, few smallers) so each deployment has more than 30MBs
> deploy directories not cleaned up
> ---------------------------------
>
> Key: AS7-6031
> URL: https://issues.jboss.org/browse/AS7-6031
> Project: Application Server 7
> Issue Type: Bug
> Affects Versions: 7.1.3.Final (EAP)
> Reporter: Shaun Appleton
> Assignee: Bartosz Baranowski
> Fix For: 7.2.0.Alpha1, 7.1.4.Final (EAP)
>
>
> JBoss EAP 6.0.0 (and 6.0.1.ER3) doesn't clean up it's tmp/vfs directories.
> The following reproduces this -
> i) ensure run.conf has the -Xrs set
> ii) ensure deployments has a deployable .ear in it
> iii) ./run standalone.sh and allow the deployments to deploy
> iv) stop the EAP process ie kill <process_id>
> v) observe content tmp/vfs
> (The -Xrs parameter is used to "-Xrs" to prevent possible interference when JVM is running as a service and receives CTRL_LOGOFF_EVENT or SIGHUP)
> This will eventually cause problems with lack of disk space.
> Note if the -Xrs parameter content is removed but the tmp/vfs dirs stills exist. This could potentially cause inode problems.
> It would be better if there were any additional code so the temp dirs are cleaned up on start up. That would resolve both the -Xrs problem and the excessive dir creation.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-430) DomainController discovery system
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-430?page=com.atlassian.jira.plugin.sy... ]
Brian Stansberry commented on AS7-430:
--------------------------------------
Re: pluggable extensions, perhaps something similar to the kind of properly typed extensions that subsystems use is overkill? Subsystem extensions fill in a really huge plugin point -- a profile. This is a much smaller scope and doesn't seem to fit as part of some larger-scoped "HC thing".
A possibility is to use a generic untyped configuration for things we don't see as good fits for the core API. Basically the name of a module, which should provide the name of a ServiceLoader-accessible SPI impl, and then key/value properties for the detail configuration.
> DomainController discovery system
> ---------------------------------
>
> Key: AS7-430
> URL: https://issues.jboss.org/browse/AS7-430
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Farah Juma
> Fix For: 7.3.0.Alpha1
>
>
> Mechanism(s) by which a Host Controller finds a Domain Controller so it can begin the process of integrating into the domain.
> Task includes the host.xml schema elements to configure this, the domain object model classes behind those elements, and the actual implementation of discovery from both the ServerManager and DomainController sides.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-4551) Force container to settle before returning from rollback management ops
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-4551?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-4551:
----------------------------------
Fix Version/s: 7.3.0.Alpha1
(was: 7.2.0.Alpha1)
Moving to 7.3. Looking at the code, the container should be forced to settle. This may not be an issue; there were some intermittent failures in some of the controller module unit tests that have been fixed and may have been what led to this issue.
> Force container to settle before returning from rollback management ops
> -----------------------------------------------------------------------
>
> Key: AS7-4551
> URL: https://issues.jboss.org/browse/AS7-4551
> Project: Application Server 7
> Issue Type: Task
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Brian Stansberry
> Fix For: 7.3.0.Alpha1
>
>
> When an operation fails and triggers rollback, the service container gets modified on the return path of the operation. But the operation does not wait for the container to settle before returning. This is the source of intermittent failures in org.jboss.as.controller.ModelControllerImplUnitTestCase.testRemoveDependentService -- the test checks container state that may not yet be settled.
> This task is to investigate forcing the container state to settle before releasing the controller lock.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months
[JBoss JIRA] (AS7-5763) timeout handling waiting for future
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/AS7-5763?page=com.atlassian.jira.plugin.s... ]
Brian Stansberry updated AS7-5763:
----------------------------------
Fix Version/s: 7.3.0.Alpha1
(was: 7.2.0.CR1)
> timeout handling waiting for future
> -----------------------------------
>
> Key: AS7-5763
> URL: https://issues.jboss.org/browse/AS7-5763
> Project: Application Server 7
> Issue Type: Bug
> Components: Domain Management
> Reporter: Alexey Loubyansky
> Assignee: Brian Stansberry
> Fix For: 7.3.0.Alpha1
>
>
> The issue was reported in AS7-5350 which points to a CLI testcase that fails on windows.
> The test starts a CLI process and deliberately specifies a wrong port for the controller expecting a failure during connection. The CLI sends a read-attribute operation request on connect to make sure the connection is working. The test is waiting for a response from the controller for 10 sec and then times out. The time out of the ModelControllerClient is 5 sec. The test still fails after 10 sec time out but the error output stream of the CLI process does contain the stack trace of the expected exception, i.e. that the controller was not available at the specified address.
> When the testcase times out, it destroys the CLI process, perhaps, this triggers some actions and the exception is finally thrown and the stack trace gets logged but it's too late.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
13 years, 6 months