[JBoss JIRA] (WFLY-3532) RemoteFailoverTestCase still fails intermittently
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3532?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz edited comment on WFLY-3532 at 1/12/15 5:10 PM:
--------------------------------------------------------------------
This test case is still failing, and in various failure modes, as before; however, in the interim, the mechanism for shutting down the server has changed. Wildfly now incorporates the SuspendController / RequestController / ControlPoint / EJBSuspendInterceptor for managing clean shutdown, whereas previous implemetations made uee of the ShutdownInterceptorFactory for shutting down EJB services in a manageable way.
It used to the the case that this test only failed on stop/start of the server. It now fails on undeploy / deploy as well as stop / start.
In the case of undeploy, the issue has been isolated and a description appears here: :https://issues.jboss.org/browse/WFLY-4234
In the case of stop / start, there are a couple of issues:
- the test case framework uses the clean shutdown mechanism but does not specify a timeout value to give running invocations, which get through before shutdown starts, a chance to finish. Thus, although clean shutdown is in place, in the test case, we are effectively simulating a shutdown in which active invocations get no time to finish
- if the shutdown timeout is adjusted so that either an invocation will get past the interceptor and have a chance to finish or an invocation will not get past the interceptor and return an EJBUnavailableException, then we still get exactly the type of exception as described above. The problem here is that if the EJBInvocationHandler has to retry an invocation on another node, due to an EJBUnavailableException, it does not correctly de-register the original invocation attempt from waiting for results coming off the original Channel; then when the channel does get closed (by the shutting down server), we get the exception described above. The fix here is, before retrying the request, make sure we de-enroll the invocation for waiting for results
was (Author: rachmato):
This test case is still failing, and in various failure modes, as before; however, in the interim, the mechanism for shutting down the server has changed. Wildfly now incorporates the SuspendController / RequestController / ControlPoint / EJBSuspendInterceptor for managing clean shutdown, whereas previous implemetations made uee of the ShutdownInterceptorFactory for shutting down EJB services in a manageable way.
It used to the the case that this test only failed on stop/start of the server. It now fails on undeploy / deploy as well as stop / start.
In the case of undeploy, the issue has been isolated and a description appears here: :https://issues.jboss.org/browse/WFLY-4234
In the case of stop / start, there are a couple of issues:
- the test case framework uses the clean shutdown mechanism but does not specify a timeout value to give running invocations, which get through before shutdown starts, a chance to finish
- if the timeout is adjusted so that either an invocation will get past the interceptor and have a chance to finish or an invocation will not get past the interceptor and return an EJBUnavailableException, then we still get exactly the type of exception as described above. The problem here is that if the EJBInvocationHandler has to retry an invocation on another node, due to an EJBUnavailableException, it does not correctly de-register the original invocation attempt from waiting for results coming off the original Channel; then when the channel does get closed (by the shutting down server), we get the exception described above. The fix here is, before retrying the request, make sure we de-enroll the invocation for waiting for results
> RemoteFailoverTestCase still fails intermittently
> --------------------------------------------------
>
> Key: WFLY-3532
> URL: https://issues.jboss.org/browse/WFLY-3532
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Richard Achmatowicz
>
> Fail rate is at 1.5% atm.
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI...
> (making affected version alpha, but indeed its master)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-3532) RemoteFailoverTestCase still fails intermittently
by Richard Achmatowicz (JIRA)
[ https://issues.jboss.org/browse/WFLY-3532?page=com.atlassian.jira.plugin.... ]
Richard Achmatowicz commented on WFLY-3532:
-------------------------------------------
This test case is still failing, and in various failure modes, as before; however, in the interim, the mechanism for shutting down the server has changed. Wildfly now incorporates the SuspendController / RequestController / ControlPoint / EJBSuspendInterceptor for managing clean shutdown, whereas previous implemetations made uee of the ShutdownInterceptorFactory for shutting down EJB services in a manageable way.
It used to the the case that this test only failed on stop/start of the server. It now fails on undeploy / deploy as well as stop / start.
In the case of undeploy, the issue has been isolated and a description appears here: :https://issues.jboss.org/browse/WFLY-4234
In the case of stop / start, there are a couple of issues:
- the test case framework uses the clean shutdown mechanism but does not specify a timeout value to give running invocations, which get through before shutdown starts, a chance to finish
- if the timeout is adjusted so that either an invocation will get past the interceptor and have a chance to finish or an invocation will not get past the interceptor and return an EJBUnavailableException, then we still get exactly the type of exception as described above. The problem here is that if the EJBInvocationHandler has to retry an invocation on another node, due to an EJBUnavailableException, it does not correctly de-register the original invocation attempt from waiting for results coming off the original Channel; then when the channel does get closed (by the shutting down server), we get the exception described above. The fix here is, before retrying the request, make sure we de-enroll the invocation for waiting for results
> RemoteFailoverTestCase still fails intermittently
> --------------------------------------------------
>
> Key: WFLY-3532
> URL: https://issues.jboss.org/browse/WFLY-3532
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Affects Versions: 9.0.0.Alpha1
> Reporter: Radoslav Husar
> Assignee: Richard Achmatowicz
>
> Fail rate is at 1.5% atm.
> http://brontes.lab.eng.brq.redhat.com/project.html?projectId=WF&testNameI...
> (making affected version alpha, but indeed its master)
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4243) Appclient resource-def annotations bindings missing in module
by Eduardo Martins (JIRA)
Eduardo Martins created WFLY-4243:
-------------------------------------
Summary: Appclient resource-def annotations bindings missing in module
Key: WFLY-4243
URL: https://issues.jboss.org/browse/WFLY-4243
Project: WildFly
Issue Type: Bug
Components: EE
Reporter: Eduardo Martins
Assignee: Eduardo Martins
Resource definitions annotated on app client component classes are missing from module, due such classes are not processed by ModuleJNDIProcessor. The abstract ResourceDefinitionAnnotationProcessor should not add such bindings to class binding configurations.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-498) Move logging tests to core
by James Perkins (JIRA)
James Perkins created WFCORE-498:
------------------------------------
Summary: Move logging tests to core
Key: WFCORE-498
URL: https://issues.jboss.org/browse/WFCORE-498
Project: WildFly Core
Issue Type: Task
Components: Test Suite
Reporter: James Perkins
Assignee: James Perkins
Priority: Minor
Integration logging tests from WildFly should be moved to core where applicable.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFLY-4242) Move logging tests to core
by James Perkins (JIRA)
James Perkins created WFLY-4242:
-----------------------------------
Summary: Move logging tests to core
Key: WFLY-4242
URL: https://issues.jboss.org/browse/WFLY-4242
Project: WildFly
Issue Type: Task
Components: Test Suite
Reporter: James Perkins
Assignee: James Perkins
Priority: Minor
Integration logging tests should be moved to core where applicable.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1905:
--------------------------------
OK, got it. So then it is either ResponseFilters and/or destination lists (+/- exclusion lists) in the RequestOptions of the RPC call...
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Paul Ferraro (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Paul Ferraro commented on JGRP-1905:
------------------------------------
Your strategy of connecting all fork channels first doesn't gel with the way WildFly provisions its channels. Infinispan is no longer the only consumer of JGroups channels, as was the case in AS7 - and thus no longer designed to control the lifecycle of the main channel. Effectively, there is no definitive set of forks for a given deployment - these are created and connected as needed by the requisite clustering services required to fulfill the components used by that deployment.
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (WFCORE-497) OperationStepHandlers for audit log handler add ops prematurely validate
by Brian Stansberry (JIRA)
Brian Stansberry created WFCORE-497:
---------------------------------------
Summary: OperationStepHandlers for audit log handler add ops prematurely validate
Key: WFCORE-497
URL: https://issues.jboss.org/browse/WFCORE-497
Project: WildFly Core
Issue Type: Bug
Components: Domain Management
Affects Versions: 1.0.0.Alpha15
Reporter: Brian Stansberry
Assignee: Brian Stansberry
Fix For: 1.0.0.Alpha16
SyslogAuditLogHandlerAddHandler and FileAuditLogHandlerAddHandler are doing reference validation directly in populateModel. This should instead be done in a separate step, removing the requirement to have the add op for the formatter occur before the add op for the handler, so long as both ops occur within the set of ops handled by the same OperationContext.
This will simplify booting from a filesystem tree instead of xml, removing the need to persist ordering information about formatter/handler in the FS.
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months
[JBoss JIRA] (JGRP-1905) FORK: RPCs might block if fork channel or fork stack is not available
by Bela Ban (JIRA)
[ https://issues.jboss.org/browse/JGRP-1905?page=com.atlassian.jira.plugin.... ]
Bela Ban commented on JGRP-1905:
--------------------------------
Sure, a ResponseFilter would also work, but what about my proposal above ?
> FORK: RPCs might block if fork channel or fork stack is not available
> ---------------------------------------------------------------------
>
> Key: JGRP-1905
> URL: https://issues.jboss.org/browse/JGRP-1905
> Project: JGroups
> Issue Type: Bug
> Reporter: Bela Ban
> Assignee: Bela Ban
> Priority: Critical
> Fix For: 3.6.2
>
>
> When we have nodes A,B,C,D, but fork-stack "fs-2" is not available on B, or fork-channel "ch-3" is not available on B, then an RPC invoked by A on all cluster nodes will time out.
> h5. Solution
> * Throw an exception on B if a fork-stack or -channel is not available on a target node. This way, the RPC would return quickly and B's response would be set to the exception (e.g. "fork channel fc-2 not available").
--
This message was sent by Atlassian JIRA
(v6.3.11#6341)
11 years, 3 months