[JBoss JIRA] (WFLY-2496) Concurrent access to ModuleSpecification causes race condition
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-2496?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-2496:
--------------------------------------
DUP's should not be adding dependencies to another deployments module spec. I think we should just fix the JSF one not to do this.
> Concurrent access to ModuleSpecification causes race condition
> --------------------------------------------------------------
>
> Key: WFLY-2496
> URL: https://issues.jboss.org/browse/WFLY-2496
> Project: WildFly
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Server
> Affects Versions: 8.0.0.Beta1
> Reporter: Jozef Hartinger
> Assignee: Jason Greene
> Priority: Blocker
> Fix For: 8.0.0.Final
>
>
> [ModuleSpecification|https://github.com/wildfly/wildfly/blob/master/server...] does not use any form of synchronization to protect its mutable state yet may be used from multiple threads in multi-module deployment when a DeploymentUnitProcessor touches ModuleSpecification of a different deployment unit which is processed at that moment.
> Here is an example of such access: https://github.com/wildfly/wildfly/blob/master/jsf/subsystem/src/main/jav...
> Here's how I think this problem manifests:
> {noformat}
> Caused by: java.lang.NullPointerException
> at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createDependencies(ModuleSpecProcessor.java:284) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.module.ModuleSpecProcessor.createModuleService(ModuleSpecProcessor.java:220) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deployModuleSpec(ModuleSpecProcessor.java:125) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.module.ModuleSpecProcessor.deploy(ModuleSpecProcessor.java:88) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159) [wildfly-server-8.0.0.Beta2-SNAPSHOT.jar:8.0.0.Beta2-SNAPSHOT]
> ... 5 more
> {noformat}
> and here's my attempt to verify concurrent access by changing the code slightly to deadlock on concurrent access:
> {noformat}
> "MSC service thread 1-6":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000f742ba28> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> at org.jboss.as.server.deployment.module.ModuleSpecification.foo(ModuleSpecification.java:170)
> at org.jboss.as.server.deployment.module.ModuleSpecification.addSystemDependency(ModuleSpecification.java:121)
> at org.jboss.as.jsf.deployment.JSFDependencyProcessor.addJSFAPI(JSFDependencyProcessor.java:115)
> at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:93)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
> - locked <0x00000000f69a8e88> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> "MSC service thread 1-3":
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000f742ba58> (a java.util.concurrent.locks.ReentrantLock$NonfairSync)
> at java.util.concurrent.locks.LockSupport.park(LockSupport.java:186)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.parkAndCheckInterrupt(AbstractQueuedSynchronizer.java:834)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireQueued(AbstractQueuedSynchronizer.java:867)
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquire(AbstractQueuedSynchronizer.java:1197)
> at java.util.concurrent.locks.ReentrantLock$NonfairSync.lock(ReentrantLock.java:214)
> at java.util.concurrent.locks.ReentrantLock.lock(ReentrantLock.java:290)
> at org.jboss.as.server.deployment.module.ModuleSpecification.foo(ModuleSpecification.java:175)
> at org.jboss.as.server.deployment.module.ModuleSpecification.addSystemDependency(ModuleSpecification.java:121)
> at org.jboss.as.jsf.deployment.JSFDependencyProcessor.addJSFAPI(JSFDependencyProcessor.java:115)
> at org.jboss.as.jsf.deployment.JSFDependencyProcessor.deploy(JSFDependencyProcessor.java:93)
> at org.jboss.as.server.deployment.DeploymentUnitPhaseService.start(DeploymentUnitPhaseService.java:159)
> - locked <0x00000000f6782960> (a org.jboss.as.server.deployment.DeploymentUnitPhaseService)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.startService(ServiceControllerImpl.java:1944)
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1877)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615)
> at java.lang.Thread.run(Thread.java:744)
> {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
12 years, 3 months
[JBoss JIRA] (WFLY-2591) CLI can not connect to the server started with port-offset
by Darran Lofthouse (JIRA)
[ https://issues.jboss.org/browse/WFLY-2591?page=com.atlassian.jira.plugin.... ]
Darran Lofthouse updated WFLY-2591:
-----------------------------------
Parent: WFLY-1597
Issue Type: Sub-task (was: Bug)
> CLI can not connect to the server started with port-offset
> ----------------------------------------------------------
>
> Key: WFLY-2591
> URL: https://issues.jboss.org/browse/WFLY-2591
> Project: WildFly
> Issue Type: Sub-task
> Security Level: Public(Everyone can see)
> Components: CLI
> Affects Versions: 8.0.0.Beta1, 8.0.0.Final
> Environment: used actual WildFly Beta from github:
> commit 96160520ce245d6a85cbb77cad92a021564aa376
> Date: Wed Nov 20 17:05:00 2013 +0100
> Reporter: Wolf-Dieter Fink
> Assignee: Darran Lofthouse
> Fix For: 8.0.0.Final
>
>
> If a standalone server is started with a binding port-offset it is not possible to connect to the native management interface.
> To reproduce start a WildFly Beta server (Alpha3 has the same problem)
> bin/standalone.sh -Djboss.socket.binding.port-offset=100
> and a cli client:
> bin/jboss-cli.sh -c --controller=localhost:10099
> It makes no difference whether the port is changed by port-offset or configuration.
> All other ports (i.e. 10090 8180) can be used correct for http-management or ejb invocation.
> The server log an ERROR message:
> ERROR [org.jboss.remoting.remote.connection] (Remoting "home:MANAGEMENT" I/O-1) JBREM000200: Remote connection failed: java.io.IOException: XNIO000804: Received an invalid message length of 1195725856
> The jboss-cli.sh client show:
> org.jboss.as.cli.CliInitializationException: Failed to connect to the controller
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:240)
> at org.jboss.as.cli.impl.CliLauncher.main(CliLauncher.java:218)
> at org.jboss.as.cli.CommandLineMain.main(CommandLineMain.java:34)
> at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
> at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:57)
> at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
> at java.lang.reflect.Method.invoke(Method.java:606)
> at org.jboss.modules.Module.run(Module.java:292)
> at org.jboss.modules.Main.main(Main.java:455)
> Caused by: org.jboss.as.cli.CommandLineException: The controller is not available at localhost:10099
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:960)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:790)
> at org.jboss.as.cli.impl.CommandContextImpl.connectController(CommandContextImpl.java:772)
> at org.jboss.as.cli.impl.CliLauncher.initCommandContext(CliLauncher.java:238)
> ... 8 more
> Caused by: java.io.IOException: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:129)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
> at org.jboss.as.cli.impl.CommandContextImpl.tryConnection(CommandContextImpl.java:938)
> ... 11 more
> Caused by: java.net.ConnectException: JBAS012174: Could not connect to http-remoting://localhost:10099. The connection failed
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:129)
> at org.jboss.as.protocol.ProtocolConnectionManager$EstablishingConnection.connect(ProtocolConnectionManager.java:256)
> at org.jboss.as.protocol.ProtocolConnectionManager.connect(ProtocolConnectionManager.java:70)
> at org.jboss.as.protocol.mgmt.FutureManagementChannel$Establishing.getChannel(FutureManagementChannel.java:204)
> at org.jboss.as.cli.impl.CLIModelControllerClient.getOrCreateChannel(CLIModelControllerClient.java:166)
> at org.jboss.as.cli.impl.CLIModelControllerClient$2.getChannel(CLIModelControllerClient.java:127)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:117)
> at org.jboss.as.protocol.mgmt.ManagementChannelHandler.executeRequest(ManagementChannelHandler.java:92)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeRequest(AbstractModelControllerClient.java:236)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:141)
> at org.jboss.as.controller.client.impl.AbstractModelControllerClient.executeForResult(AbstractModelControllerClient.java:127)
> ... 13 more
> Caused by: java.io.EOFException: XNIO000812: Connection closed unexpectedly
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:283)
> at org.xnio.http.HttpUpgrade$HttpUpgradeState$UpgradeResultListener.handleEvent(HttpUpgrade.java:266)
> at org.xnio.ChannelListeners.invokeChannelListener(ChannelListeners.java:92)
> at org.xnio.conduits.ReadReadyHandler$ChannelListenerHandler.readReady(ReadReadyHandler.java:66)
> at org.xnio.nio.NioSocketConduit.handleReady(NioSocketConduit.java:87)
> at org.xnio.nio.WorkerThread.run(WorkerThread.java:528)
> at ...asynchronous invocation...(Unknown Source)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:272)
> at org.jboss.remoting3.EndpointImpl.doConnect(EndpointImpl.java:253)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:351)
> at org.jboss.remoting3.EndpointImpl.connect(EndpointImpl.java:339)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connect(ProtocolConnectionUtils.java:80)
> at org.jboss.as.protocol.ProtocolConnectionUtils.connectSync(ProtocolConnectionUtils.java:99)
> ... 23 more
--
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, 3 months
[JBoss JIRA] (WFLY-2729) Improve reporting when persistent session restore fails
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2729?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-2729:
------------------------------
Summary: Improve reporting when persistent session restore fails (was: Exception thrown, when you try to clean server)
Issue Type: Enhancement (was: Bug)
Fix Version/s: 8.0.0.Final
(was: 8.0.0.CR1)
Affects: (was: Compatibility/Configuration)
> Improve reporting when persistent session restore fails
> -------------------------------------------------------
>
> Key: WFLY-2729
> URL: https://issues.jboss.org/browse/WFLY-2729
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: CDI / Weld
> Affects Versions: 8.0.0.CR1
> Environment: Ubuntu Linux
> Reporter: Paa Kojo Konduah Amos
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.Final
>
> Attachments: BdfHJ0fCUAAdRW5.png
>
>
> when you right clean on Server to clean it. it throws an Error
--
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, 3 months
[JBoss JIRA] (WFLY-2055) Centralize and organize I/O-related options into I/O subsystem
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-2055?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar resolved WFLY-2055.
-------------------------------
Resolution: Done
Done
> Centralize and organize I/O-related options into I/O subsystem
> --------------------------------------------------------------
>
> Key: WFLY-2055
> URL: https://issues.jboss.org/browse/WFLY-2055
> Project: WildFly
> Issue Type: Enhancement
> Security Level: Public(Everyone can see)
> Components: Remoting, Web (Undertow)
> Reporter: David Lloyd
> Assignee: Tomaz Cerar
> Fix For: 8.0.0.Final
>
>
> Centralize all the I/O related options into the I/O subsystem schema. This includes all XNIO Options, and also includes moving all XNIO worker configuration into the I/O subsystem to be referenced.
> The I/O subsystem should define types for each I/O option including (but not limited to):
> * send and receive buffer sizes
> * TCP nodelay setting
> * TCP keepalive
> * IP TOS
> * Server socket backlog
> * Server connection limit low/high water mark
> * etc.
> Also there should be types defined for:
> * XNIO worker thread count
> * XNIO worker thread stack size
> * XNIO worker thread priority
> * etc.
> Systems which define I/O entities will reference these types by including the allowed/relevant option types into their schema like the threads subsystem does for thread pool types.
> Systems presently defining workers should instead reference a worker defined in the I/O subsystem.
--
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, 3 months
[JBoss JIRA] (WFLY-2636) cli should be able to use the vault to encrypt a keystore password
by Alexey Loubyansky (JIRA)
[ https://issues.jboss.org/browse/WFLY-2636?page=com.atlassian.jira.plugin.... ]
Alexey Loubyansky resolved WFLY-2636.
-------------------------------------
Resolution: Done
'ssl' element in jboss-cli.xml now has an optional child (first child in the sequence) element 'vault', which has a required attribute 'file', the value of which could be either an absolute or a relative path to the vault XML configuration file (the content of which is generated using vault.[sh|bat]).
'vault' element also has an optional attribute 'relative-to', which if present will indicate that the value of the required attribute 'file' should be used as a relative to the value of 'relative-to' path. The value of 'relative-to' can be one of the named system-provided paths such as: jboss.home.dir, user.home or user.dir.
The following elements in the ssl configuration support vault-encrypted values:
- key-store-password;
- key-password;
- trust-store-password.
> cli should be able to use the vault to encrypt a keystore password
> ------------------------------------------------------------------
>
> Key: WFLY-2636
> URL: https://issues.jboss.org/browse/WFLY-2636
> Project: WildFly
> Issue Type: Feature Request
> Security Level: Public(Everyone can see)
> Components: CLI
> Reporter: Kabir Khan
> Assignee: Alexey Loubyansky
> Fix For: 8.0.0.Final
>
>
> The CLI can be configured for two-way SSL to connect to the management interface. The password for keystore/truststore is currently limited to being plain text inside the "jboss-cli.xml" file.
> This request is to allow a CLI client to use a local vault to encrypt those password
--
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, 3 months