[JBoss JIRA] (WFLY-4203) Failures of undeploy of a partially failed deployment
by Arcadiy Ivanov (JIRA)
Arcadiy Ivanov created WFLY-4203:
------------------------------------
Summary: Failures of undeploy of a partially failed deployment
Key: WFLY-4203
URL: https://issues.jboss.org/browse/WFLY-4203
Project: WildFly
Issue Type: Bug
Components: CLI, Domain Management
Affects Versions: 8.2.0.Final
Reporter: Arcadiy Ivanov
Assignee: Alexey Loubyansky
{noformat}
[domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups
Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers.
{noformat}
There are several issues at play here:
# Insufficient information is displayed along with JBAS010839
# No actual failure logged either in DC or in individual host's logs
# Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler
I'll start in a reverse order of causation:
in DeploymentUndeployHandler.execute
{noformat}
public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel();
...
{noformat}
OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild:
{noformat}
private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) {
if (resource.hasChild(childPath)) {
return resource.requireChild(childPath);
} else {
PathAddress missing = PathAddress.EMPTY_ADDRESS;
for (PathElement search : fullAddress) {
missing = missing.append(search);
if (search.equals(childPath)) {
break;
}
}
throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);
}
}
{noformat}
The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}:
# does not propagate from the host to DC and to CLI
# is not logged with any level (not even TRACE) either on host or DC
# should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4203) Failures of undeploy of a partially failed deployment
by Arcadiy Ivanov (JIRA)
[ https://issues.jboss.org/browse/WFLY-4203?page=com.atlassian.jira.plugin.... ]
Arcadiy Ivanov updated WFLY-4203:
---------------------------------
Description:
{noformat}
[domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups
Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers.
{noformat}
There are several issues at play here:
# Insufficient information is displayed along with JBAS010839
# No actual failure logged either in DC or in individual host's logs
# Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler
I'll start in a reverse order of causation:
In DeploymentUndeployHandler.execute
{noformat}
public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel();
...
{noformat}
OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild:
{noformat}
private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) {
if (resource.hasChild(childPath)) {
return resource.requireChild(childPath);
} else {
PathAddress missing = PathAddress.EMPTY_ADDRESS;
for (PathElement search : fullAddress) {
missing = missing.append(search);
if (search.equals(childPath)) {
break;
}
}
throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);
}
}
{noformat}
The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}:
# does not propagate from the host to DC and to CLI
# is not logged with any level (not even TRACE) either on host or DC
# should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies).
was:
{noformat}
[domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups
Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers.
{noformat}
There are several issues at play here:
# Insufficient information is displayed along with JBAS010839
# No actual failure logged either in DC or in individual host's logs
# Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler
I'll start in a reverse order of causation:
in DeploymentUndeployHandler.execute
{noformat}
public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel();
...
{noformat}
OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild:
{noformat}
private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) {
if (resource.hasChild(childPath)) {
return resource.requireChild(childPath);
} else {
PathAddress missing = PathAddress.EMPTY_ADDRESS;
for (PathElement search : fullAddress) {
missing = missing.append(search);
if (search.equals(childPath)) {
break;
}
}
throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);
}
}
{noformat}
The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}:
# does not propagate from the host to DC and to CLI
# is not logged with any level (not even TRACE) either on host or DC
# should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies).
> Failures of undeploy of a partially failed deployment
> -----------------------------------------------------
>
> Key: WFLY-4203
> URL: https://issues.jboss.org/browse/WFLY-4203
> Project: WildFly
> Issue Type: Bug
> Components: CLI, Domain Management
> Affects Versions: 8.2.0.Final
> Reporter: Arcadiy Ivanov
> Assignee: Alexey Loubyansky
>
> {noformat}
> [domain@localhost:9990 /] undeploy 2e3b75f2-88ff-4eb9-a8b1-9107c452309e.ear --all-relevant-server-groups
> Undeploy failed: JBAS010839: Operation failed or was rolled back on all servers.
> {noformat}
> There are several issues at play here:
> # Insufficient information is displayed along with JBAS010839
> # No actual failure logged either in DC or in individual host's logs
> # Failure to find a deployment unit on a particular host should not result in a failure of a domain-wide undeploy in DeploymentUndeployHandler
> I'll start in a reverse order of causation:
> In DeploymentUndeployHandler.execute
> {noformat}
> public void execute(OperationContext context, ModelNode operation) throws OperationFailedException {
> ModelNode model = context.readResourceForUpdate(PathAddress.EMPTY_ADDRESS).getModel();
> ...
> {noformat}
> OperationContextImpl.readResourceForUpdate calls OperationContextImpl.requireChild:
> {noformat}
> private static Resource requireChild(final Resource resource, final PathElement childPath, final PathAddress fullAddress) {
> if (resource.hasChild(childPath)) {
> return resource.requireChild(childPath);
> } else {
> PathAddress missing = PathAddress.EMPTY_ADDRESS;
> for (PathElement search : fullAddress) {
> missing = missing.append(search);
> if (search.equals(childPath)) {
> break;
> }
> }
> throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);
> }
> }
> {noformat}
> The exception generated by {{throw ControllerMessages.MESSAGES.managementResourceNotFound(missing);}}:
> # does not propagate from the host to DC and to CLI
> # is not logged with any level (not even TRACE) either on host or DC
> # should be handled within DeploymentUndeployHandler not to fail the undeploy operation in case of a partially failed deployment (e.g. EAR with unsatisfied CDI dependencies).
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4196) HTTP protocol violation
by Tomaz Cerar (JIRA)
[ https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin.... ]
Tomaz Cerar commented on WFLY-4196:
-----------------------------------
Or by adding filter to specific location like
{noformat}
/subsystem=undertow/server=default-server/host=default-host/location="/"/filter-ref=gzipfilter:add(predicate="path-suffix[.css, .js]")
{noformat}
where location is one of <location> defined under host.
> HTTP protocol violation
> -----------------------
>
> Key: WFLY-4196
> URL: https://issues.jboss.org/browse/WFLY-4196
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Nicolas Cazottes
> Assignee: Stuart Douglas
> Priority: Blocker
> Attachments: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war, fiddler_protocol_violation.jpg
>
>
> If you deploy the given war in wildfly and open this url http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header value.
> Actually, If the content is some js or css, the browser does not correctly reads it and the web page is corrupted.
> The explanation is that the web application uses a filter to compress the content in gzip format.
> For information, this application works correctly with jboss as 7 or before (that embed tomcat). I discovered the problem while trying to upgrade my application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4196) HTTP protocol violation
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4196:
--------------------------------------
Also you can apply the subsystem level configuration to a single application by using path-prefix[/myapplication] in the predicate (so something like predicate="path-prefix[/myapplication] and path-suffix[.js]")
> HTTP protocol violation
> -----------------------
>
> Key: WFLY-4196
> URL: https://issues.jboss.org/browse/WFLY-4196
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Nicolas Cazottes
> Assignee: Stuart Douglas
> Priority: Blocker
> Attachments: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war, fiddler_protocol_violation.jpg
>
>
> If you deploy the given war in wildfly and open this url http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header value.
> Actually, If the content is some js or css, the browser does not correctly reads it and the web page is corrupted.
> The explanation is that the web application uses a filter to compress the content in gzip format.
> For information, this application works correctly with jboss as 7 or before (that embed tomcat). I discovered the problem while trying to upgrade my application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
[JBoss JIRA] (WFLY-4196) HTTP protocol violation
by Stuart Douglas (JIRA)
[ https://issues.jboss.org/browse/WFLY-4196?page=com.atlassian.jira.plugin.... ]
Stuart Douglas commented on WFLY-4196:
--------------------------------------
So the only spec compliant way of implementing this is to wrap the HttpServletResponse object in the filter, and then intercept and discard all calls to setContentLength and setContentLengthLong (plus the general setHeader methods for content length).
Is it possible that your filter already does this, but does only does it for setContentLength and not setContentLengthLong ? This method was added in Servlet 3.1 and is used by the default servlet, so this would explain why you filter works in older versions.
> HTTP protocol violation
> -----------------------
>
> Key: WFLY-4196
> URL: https://issues.jboss.org/browse/WFLY-4196
> Project: WildFly
> Issue Type: Bug
> Components: Web (Undertow)
> Affects Versions: 8.1.0.Final, 8.2.0.Final
> Reporter: Nicolas Cazottes
> Assignee: Stuart Douglas
> Priority: Blocker
> Attachments: bug-wildfly-gzip-war-1.0.0-SNAPSHOT.war, fiddler_protocol_violation.jpg
>
>
> If you deploy the given war in wildfly and open this url http://localhost:8080/bug/images/download.png : it seems to work correctly but if you run it with fiddler2 active, fiddler reports a protocol violation on the Content-Length header value.
> Actually, If the content is some js or css, the browser does not correctly reads it and the web page is corrupted.
> The explanation is that the web application uses a filter to compress the content in gzip format.
> For information, this application works correctly with jboss as 7 or before (that embed tomcat). I discovered the problem while trying to upgrade my application.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
10 years
