[JBoss JIRA] (WFLY-4583) Do not log messages about XAResources which implement XAResourceWrapper SPI and that are known to have completed safely
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4583?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4583.
----------------------------
> Do not log messages about XAResources which implement XAResourceWrapper SPI and that are known to have completed safely
> -----------------------------------------------------------------------------------------------------------------------
>
> Key: WFLY-4583
> URL: https://issues.jboss.org/browse/WFLY-4583
> Project: WildFly
> Issue Type: Enhancement
> Components: Transactions
> Reporter: Tom Jenkinson
> Assignee: Gytis Trikleris
> Fix For: 10.0.0.Alpha1
>
>
> n the XA protocol a time window exists wherein the RM has committed and thus forgotten a tx branch but the TM has not yet deleted its log. A crash during this window currently results in an unrecoverable situation, as the TM assumes the branch belongs to an RM that is uncontactable and will retry recovery indefinitely. This stems from an inability to relate the Xid to a specific RM. It can be overridden globally with JTAEnvironmentBean.xaAssumeRecoveryComplete, but we would prefer more fine-grained control. With the availability of RM id information from XAResourceWrapper this becomes feasible.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-4716) Remove temporary code following core release
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4716?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4716.
----------------------------
> Remove temporary code following core release
> --------------------------------------------
>
> Key: WFLY-4716
> URL: https://issues.jboss.org/browse/WFLY-4716
> Project: WildFly
> Issue Type: Task
> Components: Domain Management
> Reporter: Kabir Khan
> Assignee: Kabir Khan
> Fix For: 10.0.0.Alpha3
>
>
> PR #7555 is the one introducing the temporary code. It prepares for the core release by implementing the new introduced methods, but comments out the @Override annotations so it will compile before the core release is made.
> The follow-up work will be to re-add these annotations, which have all been commented out as
> {code}
> //@Override WFLY-4716
> {code}
> and adjustments to AppClientXml
> {code}
> --- a/appclient/src/main/java/org/jboss/as/appclient/subsystem/parsing/AppClientXml.java
> +++ b/appclient/src/main/java/org/jboss/as/appclient/subsystem/parsing/AppClientXml.java
> @@ -54,8 +54,9 @@ import org.jboss.as.controller.parsing.ExtensionXml;
> import org.jboss.as.controller.parsing.Namespace;
> import org.jboss.as.controller.parsing.ParseUtils;
> import org.jboss.as.controller.persistence.ModelMarshallingContext;
> -import org.jboss.as.controller.resource.SocketBindingGroupResourceDefinition;
> import org.jboss.as.server.parsing.CommonXml;
> +import org.jboss.as.server.parsing.SocketBindingsXml;
> +import org.jboss.as.server.services.net.SocketBindingGroupResourceDefinition;
> import org.jboss.dmr.ModelNode;
> import org.jboss.dmr.Property;
> import org.jboss.modules.ModuleLoader;
> @@ -72,7 +73,7 @@ public class AppClientXml extends CommonXml {
> private final ExtensionXml extensionXml;
>
> public AppClientXml(final ModuleLoader loader, final ExtensionRegistry extensionRegistry) {
> - super();
> + super(new AppClientSocketBindingsXml());
> extensionXml = new ExtensionXml(loader, null, extensionRegistry);
> }
>
> @@ -410,4 +411,12 @@ public class AppClientXml extends CommonXml {
> throws XMLStreamException {
> // we don't marshall appclient.xml
> }
> +
> + static class AppClientSocketBindingsXml extends SocketBindingsXml {
> + @Override
> + protected void writeExtraAttributes(XMLExtendedStreamWriter writer, ModelNode bindingGroup) throws XMLStreamException {
> + SocketBindingGroupResourceDefinition.PORT_OFFSET.marshallAsAttribute(bindingGroup, writer);
> + }
> + }
> +
> }
> {code}
> Full diff at https://github.com/wildfly/wildfly/commit/2dd7eb1a3885d6496762ed399745fb1... (if github keeps these when I change my branch)
> Another thing is that AutoIgnoredResourcesDomainTestCase should be removed. It now lives in core following the work on WFCORE-401.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months
[JBoss JIRA] (WFLY-4973) Intermittent failures in client side tests that use remote EJB
by Kabir Khan (JIRA)
[ https://issues.jboss.org/browse/WFLY-4973?page=com.atlassian.jira.plugin.... ]
Kabir Khan closed WFLY-4973.
----------------------------
> Intermittent failures in client side tests that use remote EJB
> --------------------------------------------------------------
>
> Key: WFLY-4973
> URL: https://issues.jboss.org/browse/WFLY-4973
> Project: WildFly
> Issue Type: Bug
> Components: EJB
> Reporter: Stuart Douglas
> Assignee: Stuart Douglas
> Priority: Critical
> Fix For: 10.0.0.Alpha6
>
>
> There are lots of intermittent failures in tests that use remote EJB, and they all fail with the same failure message (EJBCLIENT000025: No EJB receiver available for handling...).
> An example of this is here: http://brontes.lab.eng.brq.redhat.com/viewLog.html?buildId=61476&buildTyp...
> The issue is that there is no guard to make sure that the 'module availability' message for the deployment has been processed before the test starts (there is a guard for this on initial connection, with a hard coded 5 second timeout, however the test suite will re-use connections between tests).
> At the moment I don't really have any idea of a good way to fix this.
> This failure does not affect end user code because user code does usually perform a deployment then make a call (although it could affect end user Arquillian tests).
> This issue can be reproduced 100% of the time by adding a sleep into org.jboss.ejb.client.remoting.ModuleAvailabilityMessageHandler#processMessage, then running the test suite. The first test that uses the remote EJB will pass (because the client waits for the initial module availability message), but all subsequent tests that attempt to use it will fail.
--
This message was sent by Atlassian JIRA
(v7.5.0#75005)
8 years, 5 months