June 2018 - jboss-jira - Jboss List Archives

[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ] Paul Ferraro edited comment on WFLY-10280 at 6/23/18 8:32 AM: -------------------------------------------------------------- {quote}This suplier/capability provider, funcitonal service, some sort of composite dependency and factories makes it harder to follow.{quote} I still don't understand to which code you are referring - or why you find it inherently confusing. Do you have an example? {quote}Not to mention capability org.wildfly.clustering.cache.registry-entry.ejb.client-mappings being reigstered in ejb=remote tree.{quote} There is no capability named "org.wildfly.clustering.cache.registry-entry.ejb.client-mappings". The /subsystem=ejb3/service=remote resource only registers 1 capability, named "org.wildfly.ejb.remote". See: https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... {quote}Should remote stay as a required dep or can for instance clustering provide stub service that can run in place of remoting?( just got up, so I have no idea how it works ){quote} Remoting only uses org.wildfly.clustering.ejb.AffinitySupport, which org.jboss.as.ejb3.cache.Cache (used for SFSB passivation) currently extends. This is the root of the problem. We need to decouple these interfaces and their implementations. was (Author: pferraro): {quote}This suplier/capability provider, funcitonal service, some sort of composite dependency and factories makes it harder to follow.{quote} I still don't understand to which code you are referring - or why you find it inherently confusing. Do you have an example? {quote}Not to mention capability org.wildfly.clustering.cache.registry-entry.ejb.client-mappings being reigstered in ejb=remote tree{quote}. There is no capability named "org.wildfly.clustering.cache.registry-entry.ejb.client-mappings". The /subsystem=ejb3/service=remote resource only registers 1 capability, named "org.wildfly.ejb.remote". See: https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... {quote}Should remote stay as a required dep or can for instance clustering provide stub service that can run in place of remoting?( just got up, so I have no idea how it works ){quote} Remoting only uses org.wildfly.clustering.ejb.AffinitySupport, which org.jboss.as.ejb3.cache.Cache (used for SFSB passivation) currently extends. This is the root of the problem. We need to decouple these interfaces and their implementations. > Can't enable stateful EJB passivation when EJB remote service is removed > ------------------------------------------------------------------------ > > Key: WFLY-10280 > URL: https://issues.jboss.org/browse/WFLY-10280 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 12.0.0.Final > Reporter: Ladislav Thon > Assignee: Bartosz Baranowski > Attachments: tinyEjbPassivation.war > > > In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug. > What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default). > When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry: > {code} > 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache] > service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService] > service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START] > service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService] > service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager] > service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings] > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-10280) Can't enable stateful EJB passivation when EJB remote service is removed

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-10280?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-10280: ------------------------------------- {quote}This suplier/capability provider, funcitonal service, some sort of composite dependency and factories makes it harder to follow.{quote} I still don't understand to which code you are referring - or why you find it inherently confusing. Do you have an example? {quote}Not to mention capability org.wildfly.clustering.cache.registry-entry.ejb.client-mappings being reigstered in ejb=remote tree{quote}. There is no capability named "org.wildfly.clustering.cache.registry-entry.ejb.client-mappings". The /subsystem=ejb3/service=remote resource only registers 1 capability, named "org.wildfly.ejb.remote". See: https://github.com/wildfly/wildfly/blob/master/ejb3/src/main/java/org/jbo... {quote}Should remote stay as a required dep or can for instance clustering provide stub service that can run in place of remoting?( just got up, so I have no idea how it works ){quote} Remoting only uses org.wildfly.clustering.ejb.AffinitySupport, which org.jboss.as.ejb3.cache.Cache (used for SFSB passivation) currently extends. This is the root of the problem. We need to decouple these interfaces and their implementations. > Can't enable stateful EJB passivation when EJB remote service is removed > ------------------------------------------------------------------------ > > Key: WFLY-10280 > URL: https://issues.jboss.org/browse/WFLY-10280 > Project: WildFly > Issue Type: Bug > Components: Clustering, EJB > Affects Versions: 12.0.0.Final > Reporter: Ladislav Thon > Assignee: Bartosz Baranowski > Attachments: tinyEjbPassivation.war > > > In WildFly Swarm, we don't have EJB remoting enabled by default, but would still like to be able to use stateful EJB passivation. We can't because of this bug. > What I do here is change the default SFSB cache to {{passivating}}, thereby enabling SFSB passivation, and also remove the {{remote}} service (which is what we do in WildFly Swarm by default). > When reloading the server to normal mode, deployment fails with a lot of errors, the main culprit seems to be the EJB client mappings registry: > {code} > 17:16:37,216 INFO [org.jboss.as.controller] (Controller Boot Thread) WFLYCTL0183: Service status report > WFLYCTL0184: New missing/unsatisfied dependencies: > service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache] > service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".moduleDeploymentRuntimeInformationStart, service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService, service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation, service jboss.deployment.unit."tinyEjbPassivation.war".WeldEndInitService] > service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.cache (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".component.HelloBean.START] > service jboss.undertow.deployment.default-server.default-host./tinyEjbPassivation (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".deploymentCompleteService] > service org.wildfly.clustering.cache.registry.ejb.client-mappings (unavailable) dependents: [service jboss.deployment.unit."tinyEjbPassivation.war".HelloBean.bean-manager] > service org.wildfly.clustering.cache.registry-entry.ejb.client-mappings (missing) dependents: [service org.wildfly.clustering.cache.registry.ejb.client-mappings] > {code} -- This message was sent by Atlassian JIRA (v7.5.0#75005)

8 years

1
0
0 / 0

[JBoss JIRA] (WFLY-10621) Server stop indefinitely blocked by DistributableSessionManager in lifecycleLock.writeLockInterruptibly()

by Paul Ferraro (JIRA)

[ https://issues.jboss.org/browse/WFLY-10621?page=com.atlassian.jira.plugin... ] Paul Ferraro commented on WFLY-10621: ------------------------------------- The linked forum post suggests that this issue is specific to session sharing across multiple web applications. Is this true? If so, can you update the description accordingly? And if so, can you reproduce the issue on WF12 or later? This may likely be fixed as a side effect of the changes introduced by the fix for https://issues.jboss.org/browse/WFLY-9428. > 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 > > > 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

1
0
0 / 0

[JBoss JIRA] (SWSQE-314) Create a Grafana Dashboard with Test Data