[jboss-jira] [JBoss JIRA] (WFCORE-1524) Scanner deployment failing at boot passes readiness/liveness checks
Brian Stansberry (JIRA)
issues at jboss.org
Tue May 3 12:33:00 EDT 2016
[ https://issues.jboss.org/browse/WFCORE-1524?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13200461#comment-13200461 ]
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)
More information about the jboss-jira
mailing list