[JBoss JIRA] (WFLY-4433) Potential deadlock on server shutdown
by Thomas Diesler (JIRA)
Thomas Diesler created WFLY-4433:
------------------------------------
Summary: Potential deadlock on server shutdown
Key: WFLY-4433
URL: https://issues.jboss.org/browse/WFLY-4433
Project: WildFly
Issue Type: Bug
Components: Domain Management
Affects Versions: 8.2.0.Final
Reporter: Thomas Diesler
Assignee: Brian Stansberry
Server shutdown hangs forever
{code}
[0m[0m12:05:00,818 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment example-camel-activemq-2.2.0-SNAPSHOT.war (runtime-name: example-camel-activemq-2.2.0-SNAPSHOT.war) in 1783ms
[0m[0m12:05:06,337 INFO [org.jboss.as.server.deployment] (MSC service thread 1-1) JBAS015877: Stopped deployment hawtio-1.4.42.war (runtime-name: hawtio-1.4.42.war) in 7281ms
[0m[0m12:05:06,346 INFO [org.jboss.as] (MSC service thread 1-3) JBAS015950: WildFly 8.2.0.Final "Tweek" stopped in 7297ms
[0m2015-03-16 05:25:01
Full thread dump Java HotSpot(TM) 64-Bit Server VM (25.25-b02 mixed mode):
"Thread-14" #38 daemon prio=5 os_prio=0 tid=0x00007f63b6708000 nid=0x13ad waiting for monitor entry [0x00007f6394154000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.wildfly.plugin.server.Server.stop(Server.java:108)
- waiting to lock <0x00000000c6c44650> (a org.wildfly.plugin.server.StandaloneServer)
at org.wildfly.plugin.server.SecurityActions$1.run(SecurityActions.java:58)
at java.lang.Thread.run(Thread.java:745)
"Thread-13" #37 daemon prio=5 os_prio=0 tid=0x00007f63b465f000 nid=0x13ab in Object.wait() [0x00007f63814d1000]
java.lang.Thread.State: WAITING (on object monitor)
at java.lang.Object.wait(Native Method)
at java.lang.Object.wait(Object.java:502)
at org.jboss.remoting3.spi.AbstractHandleableCloseable.close(AbstractHandleableCloseable.java:177)
- locked <0x00000000c6ac92b0> (a java.lang.Object)
at org.jboss.as.protocol.StreamUtils.safeClose(StreamUtils.java:66)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.close(RemotingModelControllerClient.java:100)
- locked <0x00000000c6ac9800> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
at org.wildfly.plugin.common.IoUtils.safeClose(IoUtils.java:37)
at org.wildfly.plugin.server.StandaloneServer.stopServer(StandaloneServer.java:77)
at org.wildfly.plugin.server.Server.stop(Server.java:108)
- locked <0x00000000c6c44650> (a org.wildfly.plugin.server.StandaloneServer)
at org.wildfly.plugin.server.SecurityActions$1.run(SecurityActions.java:58)
at java.lang.Thread.run(Thread.java:745)
"pool-2-thread-1" #45 prio=5 os_prio=0 tid=0x00007f63b5c43800 nid=0x110d waiting for monitor entry [0x00007f6394a5d000]
java.lang.Thread.State: BLOCKED (on object monitor)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient.getOrCreateChannel(RemotingModelControllerClient.java:116)
- waiting to lock <0x00000000c6ac9800> (a org.jboss.as.controller.client.impl.RemotingModelControllerClient)
at org.jboss.as.controller.client.impl.RemotingModelControllerClient$1.getChannel(RemotingModelControllerClient.java:67)
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)
at org.jboss.as.controller.client.impl.AbstractModelControllerClient.execute(AbstractModelControllerClient.java:71)
at org.wildfly.plugin.server.StandaloneServer.checkServerState(StandaloneServer.java:149)
at org.wildfly.plugin.server.Server$Reaper.run(Server.java:195)
at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:308)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.access$301(ScheduledThreadPoolExecutor.java:180)
at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:294)
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)
{code}
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-2455) Provide a way to add custom XAResource frameworks to the transaction manager
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-2455?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson updated WFLY-2455:
--------------------------------
Summary: Provide a way to add custom XAResource frameworks to the transaction manager (was: Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them)
> Provide a way to add custom XAResource frameworks to the transaction manager
> ----------------------------------------------------------------------------
>
> Key: WFLY-2455
> URL: https://issues.jboss.org/browse/WFLY-2455
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 8.0.0.Beta1
> Reporter: Koen Janssens
> Assignee: Amos Feng
>
> Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna.
> However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules.
> This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly..
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-2455) Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-2455?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-2455:
-------------------------------------
A question to the reporter though, is it a custom recovery module you need or just a way to add something to assist with custom XAResource recovery. There is quite a big difference. I am going to assume it is an XAResource you need to recover.
> Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2455
> URL: https://issues.jboss.org/browse/WFLY-2455
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 8.0.0.Beta1
> Reporter: Koen Janssens
> Assignee: Amos Feng
>
> Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna.
> However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules.
> This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly..
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-2455) Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
by Tom Jenkinson (JIRA)
[ https://issues.jboss.org/browse/WFLY-2455?page=com.atlassian.jira.plugin.... ]
Tom Jenkinson commented on WFLY-2455:
-------------------------------------
One option would be that for an app that is deployed as say a .war we could provide a facility (I think we do actually in the XARecoveryModule) to add helpers directly at runtime. That is what HQ calls today: https://github.com/jbosstm/narayana/blob/master/ArjunaJTA/jta/classes/com...
Note that that is an internal API ATM.
> Cannot configure the list of recovery modules due to ArjunaRecoveryManagerService hardcoding them
> -------------------------------------------------------------------------------------------------
>
> Key: WFLY-2455
> URL: https://issues.jboss.org/browse/WFLY-2455
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Affects Versions: 8.0.0.Beta1
> Reporter: Koen Janssens
> Assignee: Amos Feng
>
> Using a custom jbossts-properties.xml file defined via the com.arjuna.ats.arjuna.common.propertiesFile systemsetting, i can register a custom recovery manager for arjuna.
> However, the ArjunaRecoveryManagerService class overwrite the recovery configuration mentioned in my jbossts-properties.xml file with a hardcoded list of recovery modules.
> This makes me wonder if/how the hornetq recovery (org.hornetq.jms.server.recovery.HornetQXAResourceRecover) gets registered in wildfly..
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (JBRULES-1782) Decision Tree Editor
by Michael Anstis (JIRA)
[ https://issues.jboss.org/browse/JBRULES-1782?page=com.atlassian.jira.plug... ]
Michael Anstis resolved JBRULES-1782.
-------------------------------------
Resolution: Done
A Guided Decision Tree editor was added to KIE Workbench 6.1.x.
> Decision Tree Editor
> --------------------
>
> Key: JBRULES-1782
> URL: https://issues.jboss.org/browse/JBRULES-1782
> Project: JBRULES
> Issue Type: Feature Request
> Components: drools-eclipse
> Reporter: Steve Nunez
> Assignee: Michael Anstis
> Fix For: FUTURE
>
>
> While it appears that you can (in theory, I have not tried) simulate decision trees with rule flow, a 'true' decision tree editor would be a welcome addition and round out the decision metaphor offerings in drools.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4304) Servlet authentication kicked off when *not* a part of any security-constraint
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-4304?page=com.atlassian.jira.plugin.... ]
Tomas Hofman reassigned WFLY-4304:
----------------------------------
Assignee: Tomas Hofman (was: Darran Lofthouse)
> Servlet authentication kicked off when *not* a part of any security-constraint
> ------------------------------------------------------------------------------
>
> Key: WFLY-4304
> URL: https://issues.jboss.org/browse/WFLY-4304
> Project: WildFly
> Issue Type: Bug
> Affects Versions: 8.2.0.Final
> Reporter: Brett Meyer
> Assignee: Tomas Hofman
>
> Artificer runs on Wildfly 8.2 and uses Keycloak for auth. If our WAR contains a servlet that is *not* protected by a security-constraint in web.xml, Wildfly still attempts to authenticate the call (using Wireshark, I see the GET/POST get funneled through the Keycloak realm redirection) if basic auth credentials are in the header. In a keycloak-dev thread this past Dec., [~bill.burke] suggested this was most likely an issue within Wildfly auth itself.
> A credentialed call on an un-protected servlet does sound like an edge case. However, this came up possibly due to a secondary symptom:
> If I protect the servlet in web.xml, the call's Authorization header is stripped. I'm not currently able to figure out exactly where that's occurring...
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-4289) Authentication bug on one-way JAX-WS methods
by Tomas Hofman (JIRA)
[ https://issues.jboss.org/browse/WFLY-4289?page=com.atlassian.jira.plugin.... ]
Tomas Hofman reassigned WFLY-4289:
----------------------------------
Assignee: Jim Ma (was: Tomas Hofman)
> Authentication bug on one-way JAX-WS methods
> --------------------------------------------
>
> Key: WFLY-4289
> URL: https://issues.jboss.org/browse/WFLY-4289
> Project: WildFly
> Issue Type: Bug
> Components: Security, Web Services
> Affects Versions: 8.2.0.Final
> Reporter: Jakub Grabowski
> Assignee: Jim Ma
>
> 1. For two-way methods basic authentication and autorization works fine. User is authenticated with LDAP module and gets proper role that autorizes invocation. It works just fine. By two-way method I mean method with input and output message defined in WSDL.
> 2. For one-way methods (return type void) user is not authenticated properly. It results in denial of method invocation.
> 3. When I remove @RolesAllowed declaration I can see that for two-way methods authentication is correct (pricipal is set to logged user), but for one-way it's not - I get "anonymous" as principal.
> 4. When I change one-way method to have input and output messages defined in WSDL and update implementation accordingly it suprisingly starts to work as expected.
> It's quite serious issue, because currently there's no way to have authorized access to oneway webservice methods.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months
[JBoss JIRA] (WFLY-3669) Deltaspike deployment fails on wildfly 8.1
by Jozef Hartinger (JIRA)
[ https://issues.jboss.org/browse/WFLY-3669?page=com.atlassian.jira.plugin.... ]
Jozef Hartinger commented on WFLY-3669:
---------------------------------------
What does the structure of your deployment look like?
> Deltaspike deployment fails on wildfly 8.1
> ------------------------------------------
>
> Key: WFLY-3669
> URL: https://issues.jboss.org/browse/WFLY-3669
> Project: WildFly
> Issue Type: Bug
> Components: CDI / Weld
> Affects Versions: 8.1.0.Final
> Reporter: Paa Kojo Konduah Amos
> Assignee: Jozef Hartinger
>
> on addition of the Deltaspike-core dependency in my pom.xml....wildfly 8.1 fails at deployment time.
> 01:45:08,481 INFO [org.apache.deltaspike.core.util.ProjectStageProducer] (MSC service thread 1-4) Computed the following DeltaSpike ProjectStage: Production
> 01:45:12,813 ERROR [org.jboss.msc.service.fail] (MSC service thread 1-4) MSC000001: Failed to start service jboss.deployment.unit."jwi.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."jwi.war".WeldStartService: Failed to start service
> at org.jboss.msc.service.ServiceControllerImpl$StartTask.run(ServiceControllerImpl.java:1904) [jboss-msc-1.2.2.Final.jar:1.2.2.Final]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_65]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_65]
> at java.lang.Thread.run(Thread.java:745) [rt.jar:1.7.0_65]
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name dsWindowContext resolves to beans:
> Producer Method [WindowContext] with qualifiers [@Default @Named @Any] declared as [[BackedAnnotatedMethod] @Produces @Named @Dependent public org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.getWindowContext()],
> Producer Method [WindowContext] with qualifiers [@Default @Named @Any] declared as [[BackedAnnotatedMethod] @Produces @Named @Dependent public org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.getWindowContext()]
> at org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:134)
> at org.jboss.weld.bootstrap.ConcurrentValidator$5.doWork(ConcurrentValidator.java:130)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:60)
> at org.jboss.weld.executor.IterativeWorkerTaskFactory$1.call(IterativeWorkerTaskFactory.java:53)
> at java.util.concurrent.FutureTask.run(FutureTask.java:262) [rt.jar:1.7.0_65]
> ... 3 more
> 01:45:12,824 ERROR [org.jboss.as.controller.management-operation] (Controller Boot Thread) JBAS014613: Operation ("deploy") failed - address: ([("deployment" => "jwi.war")]) - failure description: {"JBAS014671: Failed services" => {"jboss.deployment.unit.\"jwi.war\".WeldStartService" => "org.jboss.msc.service.StartException in service jboss.deployment.unit.\"jwi.war\".WeldStartService: Failed to start service
> Caused by: org.jboss.weld.exceptions.DeploymentException: WELD-001414: Bean name is ambiguous. Name dsWindowContext resolves to beans:
> Producer Method [WindowContext] with qualifiers [@Default @Named @Any] declared as [[BackedAnnotatedMethod] @Produces @Named @Dependent public org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.getWindowContext()],
> Producer Method [WindowContext] with qualifiers [@Default @Named @Any] declared as [[BackedAnnotatedMethod] @Produces @Named @Dependent public org.apache.deltaspike.core.impl.scope.window.WindowContextProducer.getWindowContext()]"}}
> 01:45:12,919 INFO [org.jboss.as.server] (ServerService Thread Pool – 28) JBAS018559: Deployed "jwi.war" (runtime-name : "jwi.war")
> 01:45:12,928 INFO [org.jboss.as.controller] (Controller Boot Thread) JBAS014774: Service status report
> JBAS014777: Services which failed to start: service jboss.deployment.unit."jwi.war".WeldStartService: org.jboss.msc.service.StartException in service jboss.deployment.unit."jwi.war".WeldStartService: Failed to start service
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 4 months