[JBoss JIRA] (WFCORE-1107) DirectoryNotEmptyException on undeploy of ear
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1107?page=com.atlassian.jira.plugi... ]
Brian Stansberry reassigned WFCORE-1107:
----------------------------------------
Assignee: ehsavoie Hugonnet (was: Jason Greene)
> DirectoryNotEmptyException on undeploy of ear
> ---------------------------------------------
>
> Key: WFCORE-1107
> URL: https://issues.jboss.org/browse/WFCORE-1107
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: Oracle Solaris SPARC 10, Oracle JDK 1.8.0_45.
> Reporter: Frank Langelage
> Assignee: ehsavoie Hugonnet
>
> When undeploying my ear by removing the ear file from the standalone/deployments folder I sometimes see this exception at the end:
> 21.06. 16:49:25,674 INFO [org.jboss.as.server.deployment#stop] WFLYSRV0028: Stopped deployment maj2e-langfr-dev.ear (runtime-name: maj2e-langfr-dev.ear) in 3072ms
> 21.06. 16:49:26,034 ERROR [org.jboss.as.repository#removeContent] WFLYDR0010: Couldn't delete content /mbi/tools/jboss/10.0/standalone/data/content/30: java.nio.file.DirectoryNotEmptyException: /mbi/tools/jboss/10.0/standalone/data/content/30
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
> at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> at java.nio.file.Files.deleteIfExists(Files.java:1165)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:370)
> at org.jboss.as.server.deployment.DeploymentRemoveHandler$1$1.handleResult(DeploymentRemoveHandler.java:118)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1420)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1400)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1351)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1199)
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:956)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:904)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:620)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:373)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:349)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1201)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:747)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:741)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.controller.ModelControllerImpl$3$1.run(ModelControllerImpl.java:741)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 21.06. 16:49:26,174 INFO [org.jboss.as.repository#removeContent] WFLYDR0002: Content removed from location /mbi/tools/jboss/10.0/standalone/data/content/30/4fee5b5fa782d2a7f04723ccab3e12351d600b/content
> 21.06. 16:49:26,176 INFO [org.jboss.as.server#handleResult] WFLYSRV0009: Undeployed "maj2e-langfr-dev.ear" (runtime-name: "maj2e-langfr-dev.ear")
> The exception seems to be ignored. But the named folder and
> a file /mbi/tools/jboss/10.0/standalone/data/content/30/7cb1f70d08fb375010369eea154c5db479eaba/content are still there.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1107) DirectoryNotEmptyException on undeploy of ear
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1107?page=com.atlassian.jira.plugi... ]
Brian Stansberry updated WFCORE-1107:
-------------------------------------
Component/s: Domain Management
> DirectoryNotEmptyException on undeploy of ear
> ---------------------------------------------
>
> Key: WFCORE-1107
> URL: https://issues.jboss.org/browse/WFCORE-1107
> Project: WildFly Core
> Issue Type: Bug
> Components: Domain Management
> Environment: Oracle Solaris SPARC 10, Oracle JDK 1.8.0_45.
> Reporter: Frank Langelage
> Assignee: Jason Greene
>
> When undeploying my ear by removing the ear file from the standalone/deployments folder I sometimes see this exception at the end:
> 21.06. 16:49:25,674 INFO [org.jboss.as.server.deployment#stop] WFLYSRV0028: Stopped deployment maj2e-langfr-dev.ear (runtime-name: maj2e-langfr-dev.ear) in 3072ms
> 21.06. 16:49:26,034 ERROR [org.jboss.as.repository#removeContent] WFLYDR0010: Couldn't delete content /mbi/tools/jboss/10.0/standalone/data/content/30: java.nio.file.DirectoryNotEmptyException: /mbi/tools/jboss/10.0/standalone/data/content/30
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
> at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> at java.nio.file.Files.deleteIfExists(Files.java:1165)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:370)
> at org.jboss.as.server.deployment.DeploymentRemoveHandler$1$1.handleResult(DeploymentRemoveHandler.java:118)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1420)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1400)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1351)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1199)
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:956)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:904)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:620)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:373)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:349)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1201)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:747)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:741)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.controller.ModelControllerImpl$3$1.run(ModelControllerImpl.java:741)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 21.06. 16:49:26,174 INFO [org.jboss.as.repository#removeContent] WFLYDR0002: Content removed from location /mbi/tools/jboss/10.0/standalone/data/content/30/4fee5b5fa782d2a7f04723ccab3e12351d600b/content
> 21.06. 16:49:26,176 INFO [org.jboss.as.server#handleResult] WFLYSRV0009: Undeployed "maj2e-langfr-dev.ear" (runtime-name: "maj2e-langfr-dev.ear")
> The exception seems to be ignored. But the named folder and
> a file /mbi/tools/jboss/10.0/standalone/data/content/30/7cb1f70d08fb375010369eea154c5db479eaba/content are still there.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1107) DirectoryNotEmptyException on undeploy of ear
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-1107?page=com.atlassian.jira.plugi... ]
Brian Stansberry moved WFLY-4814 to WFCORE-1107:
------------------------------------------------
Project: WildFly Core (was: WildFly)
Key: WFCORE-1107 (was: WFLY-4814)
Affects Version/s: (was: 10.0.0.Alpha4)
> DirectoryNotEmptyException on undeploy of ear
> ---------------------------------------------
>
> Key: WFCORE-1107
> URL: https://issues.jboss.org/browse/WFCORE-1107
> Project: WildFly Core
> Issue Type: Bug
> Environment: Oracle Solaris SPARC 10, Oracle JDK 1.8.0_45.
> Reporter: Frank Langelage
> Assignee: Jason Greene
>
> When undeploying my ear by removing the ear file from the standalone/deployments folder I sometimes see this exception at the end:
> 21.06. 16:49:25,674 INFO [org.jboss.as.server.deployment#stop] WFLYSRV0028: Stopped deployment maj2e-langfr-dev.ear (runtime-name: maj2e-langfr-dev.ear) in 3072ms
> 21.06. 16:49:26,034 ERROR [org.jboss.as.repository#removeContent] WFLYDR0010: Couldn't delete content /mbi/tools/jboss/10.0/standalone/data/content/30: java.nio.file.DirectoryNotEmptyException: /mbi/tools/jboss/10.0/standalone/data/content/30
> at sun.nio.fs.UnixFileSystemProvider.implDelete(UnixFileSystemProvider.java:242)
> at sun.nio.fs.AbstractFileSystemProvider.deleteIfExists(AbstractFileSystemProvider.java:108)
> at java.nio.file.Files.deleteIfExists(Files.java:1165)
> at org.jboss.as.repository.ContentRepository$Factory$ContentRepositoryImpl.removeContent(ContentRepository.java:370)
> at org.jboss.as.server.deployment.DeploymentRemoveHandler$1$1.handleResult(DeploymentRemoveHandler.java:118)
> at org.jboss.as.controller.AbstractOperationContext$Step.invokeResultHandler(AbstractOperationContext.java:1420)
> at org.jboss.as.controller.AbstractOperationContext$Step.handleResult(AbstractOperationContext.java:1400)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeInternal(AbstractOperationContext.java:1351)
> at org.jboss.as.controller.AbstractOperationContext$Step.finalizeStep(AbstractOperationContext.java:1311)
> at org.jboss.as.controller.AbstractOperationContext$Step.access$300(AbstractOperationContext.java:1199)
> at org.jboss.as.controller.AbstractOperationContext.finishStep(AbstractOperationContext.java:956)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:904)
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:620)
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:373)
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:349)
> at org.jboss.as.controller.OperationContextImpl.executeOperation(OperationContextImpl.java:1201)
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:392)
> at org.jboss.as.controller.ModelControllerImpl.execute(ModelControllerImpl.java:223)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:747)
> at org.jboss.as.controller.ModelControllerImpl$3$1$1.run(ModelControllerImpl.java:741)
> at java.security.AccessController.doPrivileged(Native Method)
> at org.jboss.as.controller.ModelControllerImpl$3$1.run(ModelControllerImpl.java:741)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$201(ScheduledThreadPoolExecutor.java:180)
> at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:293)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)
> at java.lang.Thread.run(Thread.java:745)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> 21.06. 16:49:26,174 INFO [org.jboss.as.repository#removeContent] WFLYDR0002: Content removed from location /mbi/tools/jboss/10.0/standalone/data/content/30/4fee5b5fa782d2a7f04723ccab3e12351d600b/content
> 21.06. 16:49:26,176 INFO [org.jboss.as.server#handleResult] WFLYSRV0009: Undeployed "maj2e-langfr-dev.ear" (runtime-name: "maj2e-langfr-dev.ear")
> The exception seems to be ignored. But the named folder and
> a file /mbi/tools/jboss/10.0/standalone/data/content/30/7cb1f70d08fb375010369eea154c5db479eaba/content are still there.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4890) IronJacamar: pool gracefull flush
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4890?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-4890:
--------------------------------------
Assignee: Jesper Pedersen (was: Jason Greene)
> IronJacamar: pool gracefull flush
> ---------------------------------
>
> Key: WFLY-4890
> URL: https://issues.jboss.org/browse/WFLY-4890
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Bartosz Baranowski
> Assignee: Jesper Pedersen
> Attachments: jboss_eap_6.4.1_flush_pool_gracefully.tar.gz
>
>
> This RFE comes from EAP BZ:
> Sample implemenation of flush-all-connection-gracefully-in-pool
> Description of problem:
> A new operation for flushing all connections in pool GRACEFULLY is needed. It was available in JBoss EAP 5 and is missing in EAP 6.
> Currently JBoss EAP 6 provides two options to flush pools:
> 1) flush-idle-connection-in-pool
> Closes connections not used by application (in pool)
> 2) flush-all-connection-in-pool
> Closes all connections in pool. This operations causes exceptions on connections that are in use by application.
> A third operation is needed to flush all connections in pool without immediate kill of in-use connections. It should operate as follows:
> 1) close idle connections (just as flush-idle-connection-in-pool)
> 2) mark all in-use connections for need of destroying when returned to pool
> 3) immediately on return of connection to by application to pool close the connection
> This operation is needed to support load-balancing of connections in clusters for external providers. Examples:
> 1) JMS connections even load-balacing of connections. After JMS server restart, connections need to be reopened to evenly spread connections among servers.
> 2) Oracle RAC service migration. After the service is migrated between RAC nodes, DB connections to old node can linger for very long time (many days) to old node.
> 3) operation teams need to refresh all connections sometimes (external server maintanance)
> Version-Release number of selected component (if applicable): JBoss EAP 6.x
> How reproducible: always
> Steps to Reproduce: not possible, functionallity is missing
> Expected results: new operation available on JMS and DB pools
> Additional info: a sample implementation provided in attachment as patches to 6.4.1 (ironjacamar and jboss-as-connector). The new operation is named "flush-all-connection-gracefully-in-pool" and is available for JMS and DB pools. It doesn't modify any other places like web console, etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4890) IronJacamar: pool gracefull flush
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4890?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-4890:
-----------------------------------
Component/s: JCA
> IronJacamar: pool gracefull flush
> ---------------------------------
>
> Key: WFLY-4890
> URL: https://issues.jboss.org/browse/WFLY-4890
> Project: WildFly
> Issue Type: Feature Request
> Components: JCA
> Reporter: Bartosz Baranowski
> Assignee: Jason Greene
> Attachments: jboss_eap_6.4.1_flush_pool_gracefully.tar.gz
>
>
> This RFE comes from EAP BZ:
> Sample implemenation of flush-all-connection-gracefully-in-pool
> Description of problem:
> A new operation for flushing all connections in pool GRACEFULLY is needed. It was available in JBoss EAP 5 and is missing in EAP 6.
> Currently JBoss EAP 6 provides two options to flush pools:
> 1) flush-idle-connection-in-pool
> Closes connections not used by application (in pool)
> 2) flush-all-connection-in-pool
> Closes all connections in pool. This operations causes exceptions on connections that are in use by application.
> A third operation is needed to flush all connections in pool without immediate kill of in-use connections. It should operate as follows:
> 1) close idle connections (just as flush-idle-connection-in-pool)
> 2) mark all in-use connections for need of destroying when returned to pool
> 3) immediately on return of connection to by application to pool close the connection
> This operation is needed to support load-balancing of connections in clusters for external providers. Examples:
> 1) JMS connections even load-balacing of connections. After JMS server restart, connections need to be reopened to evenly spread connections among servers.
> 2) Oracle RAC service migration. After the service is migrated between RAC nodes, DB connections to old node can linger for very long time (many days) to old node.
> 3) operation teams need to refresh all connections sometimes (external server maintanance)
> Version-Release number of selected component (if applicable): JBoss EAP 6.x
> How reproducible: always
> Steps to Reproduce: not possible, functionallity is missing
> Expected results: new operation available on JMS and DB pools
> Additional info: a sample implementation provided in attachment as patches to 6.4.1 (ironjacamar and jboss-as-connector). The new operation is named "flush-all-connection-gracefully-in-pool" and is available for JMS and DB pools. It doesn't modify any other places like web console, etc.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4970) After removing a resource through the CLI, one with the same name can not be added
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4970?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-4970:
-----------------------------------
Component/s: (was: Security)
> After removing a resource through the CLI, one with the same name can not be added
> ----------------------------------------------------------------------------------
>
> Key: WFLY-4970
> URL: https://issues.jboss.org/browse/WFLY-4970
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: Windows 7 64-bit, Java 7
> Reporter: David Frank
> Assignee: Brian Stansberry
>
> If a resource (tested with a datasource and a security domain) is removed using the CLI, a new resource (of the same type) with the same name can not be added. The CLI shows the resource as removed, but an error will always be returned to the caller indicating that the resource already exists. In the Wildfly server log, you see a DuplicateServiceException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4970) After removing a resource through the CLI, one with the same name can not be added
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4970?page=com.atlassian.jira.plugin.... ]
Brian Stansberry updated WFLY-4970:
-----------------------------------
Component/s: Security
> After removing a resource through the CLI, one with the same name can not be added
> ----------------------------------------------------------------------------------
>
> Key: WFLY-4970
> URL: https://issues.jboss.org/browse/WFLY-4970
> Project: WildFly
> Issue Type: Bug
> Components: Security
> Affects Versions: 8.2.0.Final
> Environment: Windows 7 64-bit, Java 7
> Reporter: David Frank
> Assignee: Brian Stansberry
>
> If a resource (tested with a datasource and a security domain) is removed using the CLI, a new resource (of the same type) with the same name can not be added. The CLI shows the resource as removed, but an error will always be returned to the caller indicating that the resource already exists. In the Wildfly server log, you see a DuplicateServiceException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFCORE-1106) Better handling of subsequent changes once the server is placed into reload-required
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-1106:
----------------------------------------
Summary: Better handling of subsequent changes once the server is placed into reload-required
Key: WFCORE-1106
URL: https://issues.jboss.org/browse/WFCORE-1106
Project: WildFly Core
Issue Type: Enhancement
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Brian Stansberry
When the handler for a configuration change operation determines that it cannot effect the change to the current runtime services, it places the process into "reload-required" state. From the moment this occurs until the reload is performed, the configuration model is inconsistent with the runtime services.
This can lead to problems when, prior to reload, the user makes further configuration changes. Those changes can succeed in Stage.MODEL, since the change is valid given the current state of the configuration model, but then when the handler attempts to update the runtime the changes fail because the runtime services are in a different state. Some common scenarios:
1) User removes a resource, triggering reload required. Then they re-add the resource, which fails with a DuplicateServiceException since the service from the original version of the resource hasn't been removed yet.
2) User makes some other config change to a resource which can't be effected immediately, so the server is put into reload-required. The user then adds another resource that depends on the services from the first resource, and that add fails because the runtime service from the first resource is not in the expected state.
A naive fix for this would be once the process goes into reload-required state to stop making any further runtime changes for steps that alter the persistent config. (Runtime changes for ops that don't touch persistent config would be ok, e.g. reload itself, or runtime-only ops like popping a message off a JMS queue.)
The problem with the naive approach is config changes that could take immediate effect no longer will. This could break existing scripts, or just be annoying in general. For example, a server is in reload-required state but is still running. Then the user wants to add a logger category or change the level of an existing one in order to get some diagnostic info. The logging change would not affect the runtime until the reload is done, forcing a reload to get the diagnostic data.
Stuart Douglas had an excellent suggestion today of looking into tying this in to capabilities and requirements. So, for example:
1) An op targeted at resource foo=bar causes the process to go into reload-required.
2) The kernel detects this and finds the registration for the foo=bar resource type, and sees that the resource provides capability org.wildfly.foo.bar.
3) The kernel records in the capability registry that org.wildfly.foo.bar is now "reload-required".
4) Thereafter, for any op that changes the model and then adds a runtime step, the kernel:
a) finds the registration for the resource type associated with that op's target address
b) finds any capabilities provided by the resource type
c) looks for direct or transitive requirements for those capabilites that are "reload-required"
d) if found, the runtime step is not executed, and instead the "server-requires-reload" response-header is added.
The effect here is the granularity of what ops have their runtime changes skipped is reduced to those associated with capabilities that put the server into reload-required. Unrelated ops, e.g. the logging changes mentioned above, are unaffected.
Some fine points:
1) The restart-required and reload-required states need to be tracked separately. The information regarding any restart-required capabilities needs to survive a reload.
2) The information that a capability is reload/restart-required needs to survive the removal of the capability. This allows the remove+add scenario to work. The remove op removes the capability, but the fact it is still present in the runtime is tracked, so when the add comes in no runtime changes are made.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months
[JBoss JIRA] (WFLY-4970) After removing a resource through the CLI, one with the same name can not be added
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-4970?page=com.atlassian.jira.plugin.... ]
Brian Stansberry reassigned WFLY-4970:
--------------------------------------
Assignee: Brian Stansberry (was: Jason Greene)
> After removing a resource through the CLI, one with the same name can not be added
> ----------------------------------------------------------------------------------
>
> Key: WFLY-4970
> URL: https://issues.jboss.org/browse/WFLY-4970
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Environment: Windows 7 64-bit, Java 7
> Reporter: David Frank
> Assignee: Brian Stansberry
>
> If a resource (tested with a datasource and a security domain) is removed using the CLI, a new resource (of the same type) with the same name can not be added. The CLI shows the resource as removed, but an error will always be returned to the caller indicating that the resource already exists. In the Wildfly server log, you see a DuplicateServiceException.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)
10 years, 8 months