[JBoss JIRA] (WFLY-674) NPE in thread "vfs-shutdown"
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-674?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-674:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> NPE in thread "vfs-shutdown"
> -----------------------------
>
> Key: WFLY-674
> URL: https://issues.jboss.org/browse/WFLY-674
> Project: WildFly
> Issue Type: Bug
> Components: VFS
> Environment: 7.1.0.Alpha1 Jenkins build 1402
> Reporter: Juergen Zimmermann
> Assignee: David Lloyd
> Fix For: 8.0.0.CR1
>
>
> When I shutdown a standalone server I'm getting a NPE. The shutdown command is:
> jboss-admin.bat --connect command=:shutdown
> Console log:
> ...
> 18:24:55,990 INFO [org.jboss.as.logging] Restored bootstrap log handlers
> 18:24:55,990 INFO [org.jboss.as.jmx.JMXConnectorService] JMX remote connector stopped
> 18:24:56,075 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-as-osgi-configadmin:7.1.0.Alpha1-SNAPSHOT
> 18:24:56,125 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.log:1.0.0
> 18:24:56,230 INFO [org.apache.catalina.core.StandardContext] Container org.apache.catalina.core.ContainerBase.[jboss.web].[default-host].[/] has not been started
> 18:24:56,286 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: org.apache.felix.configadmin:1.2.8
> 18:24:56,323 INFO [org.jboss.osgi.framework.internal.HostBundleState] Bundle stopped: jboss-osgi-logging:1.0.0
> 18:24:56,330 INFO [com.arjuna.ats.jbossatx] ARJUNA32018: Destroying TransactionManagerService
> 18:24:56,331 INFO [com.arjuna.ats.jbossatx] ARJUNA32014: Stopping transaction recovery manager
> 18:24:56,368 ERROR [stderr] Exception in thread "vfs-shutdown" java.lang.NullPointerException
> 18:24:56,368 ERROR [stderr] at org.jboss.vfs.TempFileProvider$DeleteTask.run(TempFileProvider.java:151)
> 18:24:56,368 ERROR [stderr] at org.jboss.vfs.TempFileProvider.close(TempFileProvider.java:132)
> 18:24:56,368 ERROR [stderr] at org.jboss.osgi.vfs30.VirtualFileAdaptor30$2.run(VirtualFileAdaptor30.java:94)
--
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
12 years, 9 months
[JBoss JIRA] (WFLY-543) Provide an operation to request service status report after server has been started
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-543?page=com.atlassian.jira.plugin.s... ]
Jason Greene updated WFLY-543:
------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> Provide an operation to request service status report after server has been started
> -------------------------------------------------------------------------------------
>
> Key: WFLY-543
> URL: https://issues.jboss.org/browse/WFLY-543
> Project: WildFly
> Issue Type: Feature Request
> Components: Domain Management
> Reporter: Heiko Braun
> Labels: console_prio
> Fix For: 8.0.0.CR1
>
>
> For proper healthcare it would beneficial if I could verify the server status after it has been started. I.e. to catch these, which currently only appear in the server log:
> [Server:server-three] 17:48:26,636 INFO [org.jboss.as.server] (MSC service thread 1-2) Service status report
> [Server:server-three] New missing/unsatisfied dependencies:
> [Server:server-three] service jboss.binding.http2 (missing)
> [Server:server-three]
> [Server:server-three] 17:48:26,636 ERROR [org.jboss.as] (MSC service thread 1-4) JBoss AS 7.0.0.Beta4-SNAPSHOT "(TBD)" started (with errors) in 3893ms - Started 101 of 149 services (1 services failed or missing dependencies, 47 services are passive or on-demand)
--
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
12 years, 9 months
[JBoss JIRA] (WFLY-1309) CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
by Jason Greene (JIRA)
[ https://issues.jboss.org/browse/WFLY-1309?page=com.atlassian.jira.plugin.... ]
Jason Greene updated WFLY-1309:
-------------------------------
Fix Version/s: 8.0.0.CR1
(was: 8.0.0.Beta1)
> CLI: creating a server on a domain slave followed by setting a system property fails when done in batch mode
> ------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-1309
> URL: https://issues.jboss.org/browse/WFLY-1309
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Affects Versions: 8.0.0.Alpha1
> Environment: wildfly build from a git clone on 2013-05-02
> Reporter: Tom Fonteyne
> Assignee: Brian Stansberry
> Fix For: 8.0.0.CR1
>
> Attachments: host-domain-controller.xml, host-slave.xml
>
>
> Setup two boxes:
> - on one, run domain mode (full-ha) -> domain controller
> - on the other, configure host.xml to point to the DC, and run the host controller
> Now in CLI:
> # add the group:
> /server-group=slaves:add(profile=full-ha,socket-binding-group=full-ha-sockets)
> # create server and set a prop
> batch
> /host=slave1/server-config=i1:add(group=slaves,auto-start=false)
> /host=slave1/server-config=i1/system-property=env:add(value=dev)
> run-batch
> results in:
> JBAS010839: Operation failed or was rolled back on all servers.
> Debugging (on EAP 6.0.1) showed the real reason:
> activeStep.response = (org.jboss.dmr.ModelNode) {
> "outcome" => "failed",
> "failure-description" => "JBAS010850: No handler for operation
> composite at address [
> (\"host\" => \"slave1\"),
> (\"server\" => \"i1\")
> ]",
> "rolled-back" => true
> }
> More debugging led to :
> org.jboss.as.controller.AbstractOperationContext
> seems to be where the rollback is set. When debugging, I found that the constructor always sets
> ModelController.OperationTransactionControl transactionControl
> but at line 332 (eap 6.0.1) / line 372 (wildfly), the end of doCompleteStep() :
> // Allow any containing TransactionControl to vote
> final AtomicReference<ResultAction> ref = new AtomicReference<ResultAction>(transactionControl == null ? ResultAction.KEEP : ResultAction.ROLLBACK);
> and ref becomes a rollback.
> I "walked" pretty much of all the code going on in between. The bit where the config is getting persisted is successful.
> But I'm afraid I'm out of my depth as there is *a lot* going on to execute such a composite command :)
--
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
12 years, 9 months