[JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFLY-1982?page=com.atlassian.jira.plugin.... ]
Brian Stansberry commented on WFLY-1982:
----------------------------------------
Offending line:
} else if (permitHolder.get().equals(permit)) {
In tryRelease there's
permitHolder.compareAndSet(value, null);
so permitHolder.get() can return null, at least in theory.
A simple fix is to change the offending line to
} else if (Integer.valueOf(permit).equals(permitHolder.get())) {
But I haven't looked carefully enough to know whether permitHolder.get() returning null there is for some reason an unexpected state.
> NPE in ModelControllerLock
> --------------------------
>
> Key: WFLY-1982
> URL: https://issues.jboss.org/browse/WFLY-1982
> Project: WildFly
> Issue Type: Bug
> Components: Domain Management
> Reporter: Brian Stansberry
> Assignee: Emanuel Muckenhuber
> Fix For: 8.0.0.CR1
>
>
> Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
> 22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
> at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
> at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
> at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
> at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
> at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
> at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
> at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
--
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, 10 months
[JBoss JIRA] (WFLY-1982) NPE in ModelControllerLock
by Brian Stansberry (JIRA)
Brian Stansberry created WFLY-1982:
--------------------------------------
Summary: NPE in ModelControllerLock
Key: WFLY-1982
URL: https://issues.jboss.org/browse/WFLY-1982
Project: WildFly
Issue Type: Bug
Components: Domain Management
Reporter: Brian Stansberry
Assignee: Emanuel Muckenhuber
Fix For: 8.0.0.CR1
Just noticed this in the host-controller.log while looking into a non-progressing RespawnTestCase:
22:23:50,552 ERROR [org.jboss.as.controller.management-operation] (proxy-threads - 1) JBAS014612: Operation ("register-server") failed - address: ([]): java.lang.NullPointerException
at org.jboss.as.controller.ModelControllerLock$Sync.tryAcquire(ModelControllerLock.java:75) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at java.util.concurrent.locks.AbstractQueuedSynchronizer.acquireInterruptibly(AbstractQueuedSynchronizer.java:1220) [rt.jar:1.7.0_15]
at org.jboss.as.controller.ModelControllerLock.lockInterruptibly(ModelControllerLock.java:48) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.acquireLock(ModelControllerImpl.java:582) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.controller.OperationContextImpl.takeWriteLock(OperationContextImpl.java:403) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.controller.OperationContextImpl.acquireControllerLock(OperationContextImpl.java:700) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1$1.execute(ServerToHostProtocolHandler.java:268)
at org.jboss.as.controller.AbstractOperationContext.executeStep(AbstractOperationContext.java:610) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.doCompleteStep(AbstractOperationContext.java:488) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.completeStepInternal(AbstractOperationContext.java:277) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.controller.AbstractOperationContext.executeOperation(AbstractOperationContext.java:272) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.controller.ModelControllerImpl.internalExecute(ModelControllerImpl.java:257) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.controller.AbstractControllerService.internalExecute(AbstractControllerService.java:292) [wildfly-controller-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.host.controller.DomainModelControllerService.access$600(DomainModelControllerService.java:148)
at org.jboss.as.host.controller.DomainModelControllerService$InternalExecutor.execute(DomainModelControllerService.java:899)
at org.jboss.as.host.controller.mgmt.ServerToHostProtocolHandler$ServerReconnectRequestHandler$1.execute(ServerToHostProtocolHandler.java:282)
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$2$1.doExecute(AbstractMessageHandler.java:296) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at org.jboss.as.protocol.mgmt.AbstractMessageHandler$AsyncTaskRunner.run(AbstractMessageHandler.java:518) [wildfly-protocol-8.0.0.Beta1-SNAPSHOT.jar:8.0.0.Beta1-SNAPSHOT]
at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1145) [rt.jar:1.7.0_15]
at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:615) [rt.jar:1.7.0_15]
at java.lang.Thread.run(Thread.java:722) [rt.jar:1.7.0_15]
at org.jboss.threads.JBossThread.run(JBossThread.java:122) [jboss-threads-2.1.0.Final.jar:2.1.0.Final]
--
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, 10 months
[JBoss JIRA] (WFLY-1981) JSF component disappears on refresh using a4j:poll
by Frank Langelage (JIRA)
[ https://issues.jboss.org/browse/WFLY-1981?page=com.atlassian.jira.plugin.... ]
Frank Langelage updated WFLY-1981:
----------------------------------
Attachment: xaa
xab
xac
Jira-WFLY-UT.tar
As file size including war-file was 10.25 MB had to split it.
Execute "cat xa* > target.tar" to unsplit.
The tar file contains the sources only.
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
> Key: WFLY-1981
> URL: https://issues.jboss.org/browse/WFLY-1981
> Project: WildFly
> Issue Type: Bug
> Components: JSF, Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Frank Langelage
> Assignee: Stuart Douglas
> Attachments: Jira-WFLY-UT.tar, xaa, xab, xac
>
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.
--
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, 10 months
[JBoss JIRA] (WFLY-1981) JSF component disappears on refresh using a4j:poll
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1981?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar updated WFLY-1981:
------------------------------
Component/s: JSF
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
> Key: WFLY-1981
> URL: https://issues.jboss.org/browse/WFLY-1981
> Project: WildFly
> Issue Type: Bug
> Components: JSF, Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Frank Langelage
> Assignee: Stuart Douglas
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.
--
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, 10 months
[JBoss JIRA] (WFLY-1981) JSF component disappears on refresh using a4j:poll
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1981?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-1981:
-----------------------------------
It also could be issue with newer JSF/Mojarra that WF uses.
> JSF component disappears on refresh using a4j:poll
> --------------------------------------------------
>
> Key: WFLY-1981
> URL: https://issues.jboss.org/browse/WFLY-1981
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.0.0.Beta1
> Reporter: Frank Langelage
> Assignee: Stuart Douglas
>
> On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
> This does not work with WildFly build from current sources.
> Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
> I'll attach a small project showing the problem.
> The mojarra datatable works fine, is refreshed every 10 seconds.
> The openfaces datatable below disappears on first refresh.
--
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, 10 months
[JBoss JIRA] (WFLY-1981) JSF component disappears on refresh using a4j:poll
by Frank Langelage (JIRA)
Frank Langelage created WFLY-1981:
-------------------------------------
Summary: JSF component disappears on refresh using a4j:poll
Key: WFLY-1981
URL: https://issues.jboss.org/browse/WFLY-1981
Project: WildFly
Issue Type: Bug
Components: Web (Undertow)
Affects Versions: 8.0.0.Beta1
Reporter: Frank Langelage
Assignee: Stuart Douglas
On some of my pages I'm using richfaces a4j:poll to refresh components regularly. The components refreshed is an openfaces datatable.
This does not work with WildFly build from current sources.
Same code works with JBoss AS 7.20. So problem is not related to richfaces or openfaces for me. Probably related to replacement of jboss-web with undertow.
I'll attach a small project showing the problem.
The mojarra datatable works fine, is refreshed every 10 seconds.
The openfaces datatable below disappears on first refresh.
--
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, 10 months
[JBoss JIRA] (WFLY-1938) Modcluster subsystem needs transformation to 1.3.0 and 1.4.0
by Radoslav Husar (JIRA)
[ https://issues.jboss.org/browse/WFLY-1938?page=com.atlassian.jira.plugin.... ]
Radoslav Husar commented on WFLY-1938:
--------------------------------------
Model version 1.3.0 was added as part of AS7-4088 to add system properties for commonly parameterized mod_cluster configuration.
> Modcluster subsystem needs transformation to 1.3.0 and 1.4.0
> ------------------------------------------------------------
>
> Key: WFLY-1938
> URL: https://issues.jboss.org/browse/WFLY-1938
> Project: WildFly
> Issue Type: Bug
> Components: Clustering, Domain Management
> Reporter: Brian Stansberry
> Assignee: Radoslav Husar
> Priority: Critical
> Fix For: 8.0.0.CR1
>
>
> The modcluster subsystem management API has been bumped to 2.0.0 but no transformation to the previous 1.3.0 is present. Presumably the existing transformation to 1.2.0 also hasn't been updated.
> The necessary transformation needs to be added.
> EAP 6.2 will add a 1.4.0 to reflect some added metadata for RBAC (see WFLY-1936). If the 6.2. subsystem has no other management API changes, the transformation for 1.3.0 can be applied for 1.4.0 as well.
> I'm adding some TODOs for this in ModClusterExtension
--
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, 10 months
[JBoss JIRA] (WFLY-845) Cluster Environment Web Session Locks
by kelly goedert (JIRA)
[ https://issues.jboss.org/browse/WFLY-845?page=com.atlassian.jira.plugin.s... ]
kelly goedert commented on WFLY-845:
------------------------------------
I have the same problem, and upgrading to version 7.1.3 made no difference to me either
> Cluster Environment Web Session Locks
> -------------------------------------
>
> Key: WFLY-845
> URL: https://issues.jboss.org/browse/WFLY-845
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Environment: Windows 7 64bits, 8 GB RAM
> Reporter: Manuel Pinto
> Assignee: Paul Ferraro
> Fix For: 8.0.0.Alpha2
>
> Attachments: AS7-4260.patch
>
>
> Hi,
> I found a problem with web session locks in a cluster environment. We have two Liferay 6.1.1 nodes (over JBoss 7.1.1 Final) in standalone-ha.xml configuration with infinispan "web" cache-container, replicated-cache and file store. The load balancer is configured in non sticky session mode.
> Problem: when a node processes requests in some cases locks the session and never unlock it, preventing other node from processing requests for that session. The affected node never regain the locked session and keep throwing the following exception for all subsequent requests and only recover a session when other node shutdown:
> Note: we also tried invalidation-cache and distributed-cache and all locking modes but without success.
> 17:39:00,174 ERROR [org.apache.catalina.connector.CoyoteAdapter] (http--172.16.250.105-8080-4) An exception or error occurred in the container during the request processing: java.lang.RuntimeException: JBAS018060: Exception acquiring ownership of Cvn-K+r-cBGesIBoDrakJhrO
> at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:528) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.jboss.as.web.session.ClusteredSession.access(ClusteredSession.java:496) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.connector.Request.doGetSession(Request.java:2625) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.Request.getSession(Request.java:2375) [jbossweb-7.0.13.Final.jar:]
> at org.jboss.as.web.security.SecurityContextAssociationValve.invoke(SecurityContextAssociationValve.java:81) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:155) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:102) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:109) [jbossweb-7.0.13.Final.jar:]
> at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:368) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:877) [jbossweb-7.0.13.Final.jar:]
> at org.apache.coyote.http11.Http11Protocol$Http11ConnectionHandler.process(Http11Protocol.java:671) [jbossweb-7.0.13.Final.jar:]
> at org.apache.tomcat.util.net.JIoEndpoint$Worker.run(JIoEndpoint.java:930) [jbossweb-7.0.13.Final.jar:]
> at java.lang.Thread.run(Thread.java:662) [rt.jar:1.6.0_32]
> Caused by: org.jboss.as.clustering.lock.TimeoutException: JBAS010223: Cannot acquire lock //default-host//Cvn-K+r-cBGesIBoDrakJhrO from cluster
> at org.jboss.as.clustering.lock.SharedLocalYieldingClusterLockManager.lock(SharedLocalYieldingClusterLockManager.java:439)
> at org.jboss.as.clustering.web.infinispan.DistributedCacheManager.acquireSessionOwnership(DistributedCacheManager.java:372)
> at org.jboss.as.web.session.ClusteredSession.acquireSessionOwnership(ClusteredSession.java:520) [jboss-as-web-7.1.1.Final.jar:7.1.1.Final]
> ... 12 more
> The standalone-ha.xml "web" cache-container config is the following:
> <cache-container name="web" aliases="standard-session-cache" default-cache="repl">
> <transport lock-timeout="60000"/>
> <replicated-cache name="repl" mode="SYNC" batching="true">
> <file-store/>
> </replicated-cache>
> <replicated-cache name="sso" mode="SYNC" batching="true"/>
> <distributed-cache name="dist" mode="ASYNC" batching="true">
> <file-store/>
> </distributed-cache>
> </cache-container>
> Thanks,
> Manuel Pinto
--
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, 10 months