[
https://issues.jboss.org/browse/WFCORE-1524?page=com.atlassian.jira.plugi...
]
Brian Stansberry commented on WFCORE-1524:
------------------------------------------
[~ehugonnet] Quick speculation:
I think this all relates to how we handle boot ops. The scanner generated deployment ops
are inserted as steps into the overall boot op (the 2nd op, that does subsystems.)
That overall op does not fail because we have rollback-on-runtime-failure set to false.
But I suspect we are losing track of what is happening to the particular steps that are
added by the scanner and therefore are not reporting things correctly.
Scanner deployment failing at boot passes readiness/liveness checks
-------------------------------------------------------------------
Key: WFCORE-1524
URL:
https://issues.jboss.org/browse/WFCORE-1524
Project: WildFly Core
Issue Type: Bug
Components: Deployment Scanner, Domain Management
Environment:
brew-pulp-docker01.web.prod.ext.phx2.redhat.com:8888/jboss-eap-7/eap70-openshift:1.3-11
Reporter: Marek Schmidt
Assignee: ehsavoie Hugonnet
During larger scale-ups (e.g. from 1 to 6 on nodes under load) deployments sometimes fail
with "org.infinispan.util.concurrent.TimeoutException: Replication timeout for
foo-1-xxxxx".
That by itself is expected with the default timeouts, however, the problem is that such
failed deployments pass the default EAP readiness and liveness checks, which results in
HTTP 404 responses.
--
This message was sent by Atlassian JIRA
(v6.4.11#64026)