[JBoss JIRA] (WFCORE-3039) Capability requirement can be lost if two attributes on same resource reference the same capability
by Jeff Mesnil (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3039?page=com.atlassian.jira.plugi... ]
Jeff Mesnil commented on WFCORE-3039:
-------------------------------------
I quickly looked at the code related to this failure.
In org.jboss.as.controller.OperationContext#registerAdditionalCapabilityRequirement, the method accepts an attribute parameter whose javadoc says "the name of the attribute that triggered this requirement, or {@code null} if no single attribute was responsible"
However in org.jboss.as.controller.AbstractAddStepHandler#recordCapabilitiesAndRequirements, when we record the requirements for the resource, we do:
1. add capability requirements for each attribute of the resource
2. get the context's resourceRegistration
3. for each requirements, we add capability requirements without specifying the attribute that triggered the requirement[1]
It seems that we should properly tracked the attribute that was responsible of the capability requirements in order to distinguish the "combined-providers" capability coming from either the final-providers or initial-provides attribute.
[1] https://github.com/wildfly/wildfly-core/blob/0e204bdabbe1ac8766cc59c9d259... where attributeName is null
> Capability requirement can be lost if two attributes on same resource reference the same capability
> ---------------------------------------------------------------------------------------------------
>
> Key: WFCORE-3039
> URL: https://issues.jboss.org/browse/WFCORE-3039
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Reporter: Darran Lofthouse
> Assignee: Radovan Netuka
>
> With the following three commands the server becomes unable to boot due to a missing dependency: -
> {noformat}
> /subsystem=elytron:write-attribute(name=initial-providers, value=combined-providers)
> /subsystem=elytron:undefine-attribute(name=final-providers)
> /subsystem=elytron/aggregate-providers=combined-providers:remove
> {noformat}
> If however I execute :reload after the first two commands, the final command will fail correctly.
> {noformat}
> [standalone@localhost:9990 /] /subsystem=elytron/aggregate-providers=combined-providers:remove
> {
> "outcome" => "failed",
> "failure-description" => "WFLYCTL0367: Cannot remove capability 'org.wildfly.security.providers.combined-providers' as it is required by other capabilities:
> capability 'org.wildfly.security.elytron' requires it for attribute 'initial-providers' at address '/subsystem=elytron'",
> "rolled-back" => true
> }
> {noformat}
> I am only listing the 'Domain Management' component as I believe the security example is just the reproducer.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10621) Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()
by Petr H (JIRA)
[ https://issues.jboss.org/browse/WFLY-10621?page=com.atlassian.jira.plugin... ]
Petr H commented on WFLY-10621:
-------------------------------
So as expected, reproduced at WildFly 13 as well. See the attached thread dump [^threaddump-wfly13-stop-blocked.txt].
> Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10621
> URL: https://issues.jboss.org/browse/WFLY-10621
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Environment: CentOS 7.4.1708
> Java 1.8.0_172-b11
> WildFly 11.0.0.Final
> Reporter: Petr H
> Assignee: Paul Ferraro
> Labels: clustering, sessions
> Attachments: threaddump-wfly11-stop-blocked.txt, threaddump-wfly13-stop-blocked.txt
>
>
> Note: This is report for the issue reported here first https://developer.jboss.org/thread/277883
> It can be seen at WildFly 11 and EAP 7.1 at least, however as the particular code in the DistributableSessionManager class seems to be unchanged even in WildFly 13 it's likely to occur there as well. (We test WildFly 11 because it's closest to the EAP 7.1 which is being considered for the production use later in this project)
> Stop server operation may hang indefinitely due to the thread such as the following one being blocked:
> {noformat}
> "ServerService Thread Pool -- 24" #49 prio=5 os_prio=0 tid=0x00000000035d1000 nid=0x4de1 waiting on condition [0x00007f4bddc46000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000c4e61998> (a java.util.concurrent.locks.StampedLock)
> at java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1119)
> at java.util.concurrent.locks.StampedLock.writeLockInterruptibly(StampedLock.java:413)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.stop(DistributableSessionManager.java:90)
> - locked <0x00000000c4e60090> (a org.wildfly.clustering.web.undertow.session.DistributableSessionManager)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:599)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:589)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1005/749195997.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:603)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> The related code in the DistributableSessionManager makes use of the [java.util.concurrent.locks.StampedLock.writeLockInterruptibly()|https://d...] method which can theoretically block indefinitely and thus prevent the server stop from ever completing.
> The change was introduced in the following commit [WFLY-7695 Block session manager stop until all sessions are closed|https://github.com/wildfly/wildfly/commit/94863deeb96c4536ec5e8266...]
> This can occur even in non-clustered environments (non-HA profile) with web applications just being marked as distributable (web.xml).
> We don't know what prevents the lock from being obtained (unable to determine from the thread dump) so we can't unfortunately do much about it at the moment from the application side.
> We only tried to change the infinispan web local-cache configuration due to _ISPN000136_ errors intermittedly occurring, but that seems to have no effect. We tried various combinations of *locking isolation* (REPEATABLE_READ, READ_COMMITED), *transaction locking* (OPTIMISTIC, PESSIMISTIC) and *transaction mode* (NONE, BATCH) settings and it seems to occur with all of them.
> Note: The issue doesn't occur always, only in some cases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10621) Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()
by Petr H (JIRA)
[ https://issues.jboss.org/browse/WFLY-10621?page=com.atlassian.jira.plugin... ]
Petr H updated WFLY-10621:
--------------------------
Attachment: threaddump-wfly13-stop-blocked.txt
> Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()
> ---------------------------------------------------------------------------------------------------------
>
> Key: WFLY-10621
> URL: https://issues.jboss.org/browse/WFLY-10621
> Project: WildFly
> Issue Type: Bug
> Components: Clustering
> Affects Versions: 11.0.0.Final
> Environment: CentOS 7.4.1708
> Java 1.8.0_172-b11
> WildFly 11.0.0.Final
> Reporter: Petr H
> Assignee: Paul Ferraro
> Labels: clustering, sessions
> Attachments: threaddump-wfly11-stop-blocked.txt, threaddump-wfly13-stop-blocked.txt
>
>
> Note: This is report for the issue reported here first https://developer.jboss.org/thread/277883
> It can be seen at WildFly 11 and EAP 7.1 at least, however as the particular code in the DistributableSessionManager class seems to be unchanged even in WildFly 13 it's likely to occur there as well. (We test WildFly 11 because it's closest to the EAP 7.1 which is being considered for the production use later in this project)
> Stop server operation may hang indefinitely due to the thread such as the following one being blocked:
> {noformat}
> "ServerService Thread Pool -- 24" #49 prio=5 os_prio=0 tid=0x00000000035d1000 nid=0x4de1 waiting on condition [0x00007f4bddc46000]
> java.lang.Thread.State: WAITING (parking)
> at sun.misc.Unsafe.park(Native Method)
> - parking to wait for <0x00000000c4e61998> (a java.util.concurrent.locks.StampedLock)
> at java.util.concurrent.locks.StampedLock.acquireWrite(StampedLock.java:1119)
> at java.util.concurrent.locks.StampedLock.writeLockInterruptibly(StampedLock.java:413)
> at org.wildfly.clustering.web.undertow.session.DistributableSessionManager.stop(DistributableSessionManager.java:90)
> - locked <0x00000000c4e60090> (a org.wildfly.clustering.web.undertow.session.DistributableSessionManager)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:599)
> at io.undertow.servlet.core.DeploymentManagerImpl$3.call(DeploymentManagerImpl.java:589)
> at io.undertow.servlet.core.ServletRequestContextThreadSetupAction$1.call(ServletRequestContextThreadSetupAction.java:42)
> at io.undertow.servlet.core.ContextClassLoaderSetupAction$1.call(ContextClassLoaderSetupAction.java:43)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction.lambda$create$0(SecurityContextThreadSetupAction.java:105)
> at org.wildfly.extension.undertow.security.SecurityContextThreadSetupAction$$Lambda$1005/749195997.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction.lambda$create$0(UndertowDeploymentInfoService.java:1508)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentInfoService$UndertowThreadSetupAction$$Lambda$1006/1165195653.call(Unknown Source)
> at io.undertow.servlet.core.DeploymentManagerImpl.stop(DeploymentManagerImpl.java:603)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService.stopContext(UndertowDeploymentService.java:139)
> at org.wildfly.extension.undertow.deployment.UndertowDeploymentService$2.run(UndertowDeploymentService.java:120)
> at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:511)
> at java.util.concurrent.FutureTask.run(FutureTask.java:266)
> at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1149)
> at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:624)
> at java.lang.Thread.run(Thread.java:748)
> at org.jboss.threads.JBossThread.run(JBossThread.java:320)
> {noformat}
> The related code in the DistributableSessionManager makes use of the [java.util.concurrent.locks.StampedLock.writeLockInterruptibly()|https://d...] method which can theoretically block indefinitely and thus prevent the server stop from ever completing.
> The change was introduced in the following commit [WFLY-7695 Block session manager stop until all sessions are closed|https://github.com/wildfly/wildfly/commit/94863deeb96c4536ec5e8266...]
> This can occur even in non-clustered environments (non-HA profile) with web applications just being marked as distributable (web.xml).
> We don't know what prevents the lock from being obtained (unable to determine from the thread dump) so we can't unfortunately do much about it at the moment from the application side.
> We only tried to change the infinispan web local-cache configuration due to _ISPN000136_ errors intermittedly occurring, but that seems to have no effect. We tried various combinations of *locking isolation* (REPEATABLE_READ, READ_COMMITED), *transaction locking* (OPTIMISTIC, PESSIMISTIC) and *transaction mode* (NONE, BATCH) settings and it seems to occur with all of them.
> Note: The issue doesn't occur always, only in some cases.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10616) ContextResolver doesn't work
by George Trudeau (JIRA)
[ https://issues.jboss.org/browse/WFLY-10616?page=com.atlassian.jira.plugin... ]
George Trudeau commented on WFLY-10616:
---------------------------------------
I have attached a minimal WAR which contains sources.
> ContextResolver doesn't work
> ----------------------------
>
> Key: WFLY-10616
> URL: https://issues.jboss.org/browse/WFLY-10616
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 13.0.0.Final
> Reporter: George Trudeau
> Assignee: R Searls
> Fix For: 14.0.0.CR1
>
> Attachments: test.war
>
>
> I have a simple ContextResolver to set Date serialization format for my JAX-RS service, it works on 12.0.0.Final but it doesn't anymore on 13.0.0.Final :
> {code:java}
> @Provider
> public class DateResolver implements ContextResolver<ObjectMapper>
> {
> private final ObjectMapper mapper;
> public DateResolver()
> {
> mapper = new ObjectMapper();
> mapper.setDateFormat(new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ"));
> mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
> }
> @Override
> public ObjectMapper getContext(Class<?> type) { return mapper; }
> }
> {code}
> The {{getContext}} method isn't called on 13.0.0.Final.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10616) ContextResolver doesn't work
by George Trudeau (JIRA)
[ https://issues.jboss.org/browse/WFLY-10616?page=com.atlassian.jira.plugin... ]
George Trudeau updated WFLY-10616:
----------------------------------
Attachment: test.war
> ContextResolver doesn't work
> ----------------------------
>
> Key: WFLY-10616
> URL: https://issues.jboss.org/browse/WFLY-10616
> Project: WildFly
> Issue Type: Bug
> Components: REST
> Affects Versions: 13.0.0.Final
> Reporter: George Trudeau
> Assignee: R Searls
> Fix For: 14.0.0.CR1
>
> Attachments: test.war
>
>
> I have a simple ContextResolver to set Date serialization format for my JAX-RS service, it works on 12.0.0.Final but it doesn't anymore on 13.0.0.Final :
> {code:java}
> @Provider
> public class DateResolver implements ContextResolver<ObjectMapper>
> {
> private final ObjectMapper mapper;
> public DateResolver()
> {
> mapper = new ObjectMapper();
> mapper.setDateFormat(new SimpleDateFormat("yyyy-MM-dd'T'HH:mm:ssZ"));
> mapper.disable(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS);
> }
> @Override
> public ObjectMapper getContext(Class<?> type) { return mapper; }
> }
> {code}
> The {{getContext}} method isn't called on 13.0.0.Final.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFLY-10520) Add Hibernate ORM 5.3 compatibility transformer
by Scott Marlow (JIRA)
[ https://issues.jboss.org/browse/WFLY-10520?page=com.atlassian.jira.plugin... ]
Scott Marlow commented on WFLY-10520:
-------------------------------------
[~gbadner] I fetched your changes locally and see the results that you mention. I did ask a question on the pr.
Regarding moving the handling of setFirstResult( -1 ), to the migration guide, if #setHibernateFirstResult cannot handle the negative value, we should definitely document that negative values should not be passed to setFirstResult anymore.
> Add Hibernate ORM 5.3 compatibility transformer
> -----------------------------------------------
>
> Key: WFLY-10520
> URL: https://issues.jboss.org/browse/WFLY-10520
> Project: WildFly
> Issue Type: Task
> Components: JPA / Hibernate
> Reporter: Gail Badner
> Assignee: Scott Marlow
> Fix For: 14.0.0.CR1
>
>
> A compatibility transformer needs to be added to address Hibernate ORM 5.3 API methods that are no longer compatible with 5.1.
> From https://docs.google.com/document/d/1cAVBdeQXQfpTwH0f_GKSahh_gRd7bKI6kII-w...
> # Change call to org.hibernate.BasicQueryContract.getFlushMode() to instead call BasicQueryContract.getHibernateFlushMode().
> # Change call to org.hibernate.Session.getFlushMode, to instead call Session.getHibernateFlushMode()
> # Modify calls to org.hibernate.Query.getFirstResult() to convert returned int, to Integer result.
> # Modify calls to org.hibernate.Query.getMaxResults() to convert returned int, to Integer result, if returned int value is <= 0, null should be used, if Integer.MAX_VALUE is, the transformer should replace with null reference.
> # App References to Enum org.hibernate.FlushMode.NEVER (0) should be transformed to reference FlushMode.MANUAL (0) instead.
> # For call to org.hibernate.Query.setMaxResults(int), instead call org.hibernate.Query.setHibernateMaxResults(int) which will be added soon to ORM 5.3.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years
[JBoss JIRA] (WFCORE-3937) Error when running configured wildfly
by Brian Stansberry (JIRA)
[ https://issues.jboss.org/browse/WFCORE-3937?page=com.atlassian.jira.plugi... ]
Brian Stansberry commented on WFCORE-3937:
------------------------------------------
[~jmesnil] Stephen's technique for cleaning up lessens my enthusiasm for my "--no-history option" suggestion quite a lot, as it seems like a better technique for cleaning since it eliminates other FS modifications as well beyond the config history.
> Error when running configured wildfly
> -------------------------------------
>
> Key: WFCORE-3937
> URL: https://issues.jboss.org/browse/WFCORE-3937
> Project: WildFly Core
> Issue Type: Bug
> Components: Management
> Affects Versions: 5.0.0.Final
> Reporter: Stephen Buergler
> Assignee: Jeff Mesnil
> Priority: Minor
> Attachments: Dockerfile
>
>
> 08:32:20,676 ERROR [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0056: Could not rename /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current to /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/20180619-083220673: java.nio.file.DirectoryNotEmptyException: /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current
> ...
> 08:50:08,531 WARN [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0414: Could not create a timestamped backup of current history dir /opt/jboss/wildfly/standalone/configuration/standalone_xml_history/current, so it may still include versions from the previous boot.
> To reproduce:
> docker build -t testing .
> docker run --rm -it testing
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years