[ https://issues.jboss.org/browse/WFLY-6225?page=com.atlassian.jira.plugin.... ] Ladislav Thon updated WFLY-6225: -------------------------------- Description: During a 2clusters test eap-7x-failover-ejb-2clusters-ejbremote-shutdown-repl-async (where 2clusters test = standalone EJB client -> 2-node "forwarder" cluster -> 2-node "target" cluster -> back to "forwarder" -> back to standalone client), I'm seeing {{javax.ejb.EJBException: java.lang.ClassNotFoundException: org.infinispan.util.concurrent.TimeoutException from \[Module "deployment.clusterbench-ee7.ear.clusterbench-ee7-ejb.jar:main" from Service Module Loader\]}} being thrown from an in-server EJB client. The {{TimeoutException}}-s are due to WFLY-5809, as can be seen by comparing the parsed logs: [log messages with "TimeoutException: Unable to acquire lock"|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-fa...] and [log messages with "TimeoutException" only|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover...]. This sounds very similar to WFLY-5788, except that in this case, the EJB client is inside the server. The EJB JAR subdeployment probably doesn't have a dependency on {{org.infinispan}}, but in previous EAP 7 ERs, this wasn't a problem and there were no CNFEs even though there _were_ the {{TimeoutException}}-s. (BTW, there's another subdeployment that has the dependency.) This is new in EAP 7.0.0.ER5, which is why I'm filing it separately from WFLY-5788. was: During a 2clusters test eap-7x-failover-ejb-2clusters-ejbremote-shutdown-repl-async (where 2clusters test = standalone EJB client -> 2-node "forwarder" cluster -> 2-node "target" cluster -> back to "forwarder" -> back to standalone client), I'm seeing {{javax.ejb.EJBException: java.lang.ClassNotFoundException: org.infinispan.util.concurrent.TimeoutException from \[Module "deployment.clusterbench-ee7.ear.clusterbench-ee7-ejb.jar:main" from Service Module Loader\]}} being thrown from an in-server EJB client. The {{TimeoutException}}-s are due to JBEAP-2273, as can be seen by comparing the parsed logs: [log messages with "TimeoutException: Unable to acquire lock"|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-fa...] and [log messages with "TimeoutException" only|https://jenkins.mw.lab.eng.bos.redhat.com/hudson/job/eap-7x-failover...]. This sounds very similar to JBEAP-2159, except that in this case, the EJB client is inside the server. The EJB JAR subdeployment probably doesn't have a dependency on {{org.infinispan}}, but in previous EAP 7 ERs, this wasn't a problem and there were no CNFEs even though there _were_ the {{TimeoutException}}-s. (BTW, there's another subdeployment that has the dependency.) This is new in EAP 7.0.0.ER5, which is why I'm filing it separately from JBEAP-2159. -- This message was sent by Atlassian JIRA (v6.4.11#64026)